Re: OT - Spaces in file and directory names (was: Alias syntax fo r a m odule that has a space in its name)
This whole discussion, OT though it might be, reminds me of a recent discussion of the "proper" way of quoting things (use of backquotes and apostrophes and such). I think that discussion was also on this list, though I thought the outcome was more opposite than parallel to the outcome of this one. FWIW, mostly as an amusing side note. On Fri, Apr 22, 2005 at 11:39:06AM -0400, Jim.Hyslop wrote: Bulgrien, Kevin wrote: > It is easy to tell everyone else what they ought to do in hind-sight. Nobody's doing that. I clearly acknowledged that *when these applications were written*, handling spaces was extremely difficult to do. I'm not denegrating the years of hard work that went into various tools, nor am I saying we should retrofit all applications. What I object to is the attitude "spaces in file names are evil," the phrase that kicked off this (as you correctly pointed out) off-topic discussion. That attitude is outmoded, and reeks of a calcified mentality that refuses to accept change. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com "You must let me try, for a true soldier does not admit defeat before the battle." --Helen Keller (in a letter to the president of Radcliffe College) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: checking out multiple branches of a project
On Thu, Apr 21, 2005 at 09:20:04AM -0400, Jim.Hyslop wrote: > Chris Cheshire wrote: > > I have a project in source control called mylib (for example) that > > contains libraries used for my various programs. Currently I need to > > make some changes to a development branch, as well as some changes to > > the head. I have been deleting one, checking out the other, > > deleting it, > > checking out the original one again constantly, and it is starting to > > get annoying. Is there any way I can check it out so that the > > structure > > looks something like : > > > > ~/src/mylib/HEAD/... > > ~/src/mylib/dev-branch/... > > Sure, piece of cake. Check out [sic] the -d option to the checkout command. I have often wished for an automatic way to check out all existing branches of a given module with one command. Example: If I have module mymod with HEAD and branches named rel1 and rel2: mkdir cvs_co cd cvs_co cvs co -b mymod cd mymod ls # would list HEAD (or head), rel1, and rel2, and probably CVS) The -b option is of course ficticious. > > -- > Jim Hyslop > Senior Software Designer > Leitch Technology International Inc. ( http://www.leitch.com ) > Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com Freedom is not the ability to have what we want. Freedom is merely the ability to seek it. To be free defines what we can do, not what we can get. (03/28/05) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
On Mon, Apr 04, 2005 at 01:57:22AM +, Pierre Asselin wrote: > Doug Lee <[EMAIL PROTECTED]> wrote: > > > Now for why... > > > I write scripts for a screen-reading program called JAWS For Windows > > (JAWS stands for Job Access With Speech). JAWS scripts must all exist > > and run in a specific directory, say c:\jaws510\settings\enu. JAWS > > scripts are named after the applications to which they apply; thus, a > > script for WordPad will be named WordPad.jss (source code; the > > compiled version is WordPad.jsb, and there are other associated > > > WordPad.* files as well). Every script for every application that > > needs special handling goes in the same directory. This is how it > > comes to pass that I often have multiple simultaneous projects in the > > same directory with no overlapping file names. > > I see. Well, allow me to pontificate a little. Your files are > scripts and require no compilation, so you make the common mistake Just for complete accuracy: They are indeed compiled, but both source and binary reside in the same place. The rest of your message is accurate, though I hesitate to say "JAWS is not nice"; for the situation being solved by JAWS, it makes sense to me. In the newest JAWS version, scripts (source and binary) go under a massively long but more modern path like C:\Documents and Settings\\Application Data\Freedom Scientific\JAWS\6.0\Settings\enu ... but the problem is still the same for CVS management. > of confusing the *source tree* of your project (your scripts) with > the *installed version* of your project (your scripts in > jaws510\settings\enu with all their other script friends). The > source tree goes into CVS, the installed copy doesn't. You should > be doing a "make install" or some such to install your files... > > ... except that it sucks, because you can't even *test* your scripts > without installing them. Which is why the above qualifies as > pontification. Bottom line: JAWS is not nice, and there is nothing > you can do about it. Doesn't stop me from trying. :-) Seriously though, CVS just happens to be a WONDERFUL assistant with this because of its ability to track which of the many settings\enu files matter to a project. It also helps me catch modifications to configuration files that I might otherwise make and miss accidentally: app.jcf files are text config files, so if I include them in a project on site, at the end I can capture the changes I had to make there just as easily as I capture code. The original problem I set out to address here though was how to move repo subtrees around without all the case-change problems this currently can cause. As I think I've accidentally made more of an education about JAWS than a discussion of that question here though, I think I'll consider the matter closed unless someone has a brainstorm. :-) > Or does JAWS understand shell links (aka Windows shortcuts) ? If > yes, you could plant shortcuts from the installation directory to > your CVS sandbox. Is there a tool to plant shortcuts programmatically? I don't think JAWS can compile an app.lnk that points to c:\cvs\proj\app.jss, but even greater a problem, app.jss tends to come with app.jsd, and app.lnk can't point to both at once... Nice idea though; it hadn't occurred to me. > One other thing: are you the only one involved that uses CVS? if > so I guess your approach is okay, but your initial post said > something about telling everyone else to stop committing to the > trunk while you were away. That negates the "C" in CVS, which is > a shame. I'm not the only CVS user here (though I'm sorta the one that started it here), but I've never had a case where one person was at a client site committing and someone else was in the office committing to the same project. (And I hear Jim's "Yet" echoing after me...) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com "You must let me try, for a true soldier does not admit defeat before the battle." --Helen Keller (in a letter to the president of Radcliffe College) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management ?
On Mon, Apr 04, 2005 at 09:44:21AM -0400, Jim.Hyslop wrote: > In your first message, the part "Tell everyone that they should not modify > the central tree" really scares (and annoys) me. Generally, the only > operations where you should tell people not to check things in are > maintenance operations that affect the repository directly. Forgive me here please, but I understand neither what scares and annoys you, nor what you suggest. I tell people not to check in because I have the "active" part of the tree off site at that time. I could (and probably should) lock it somehow, but I don't want to disable READ access to it, because others may want to see it. But while I'm working directly with the client, it makes little sense for anyone else off site to check into that tree anyway, so there's never been a problem there. > For your "thousand files in a single directory" issue, you could use the -d > option in the CVS/modules file to specify that the project should be checked > out into a directory named enu. That would eliminate you having to use the > -d option each time you check out a project. The modules file might look > something like: > > wordpad -s dev -d enu path/in/repository True, but we do sometimes check out elsewhere; for instance, I'm trying to set up a build system that checks out a fresh copy from which to build an installer. For now though, whenever I make a release, I often do check out outside of settings\enu. > For your basic procedures, I would suggest something like this: > > - apply a tag to the files you're going to take on-site > - 'CVS export' those files > - On-site, use 'cvs import' to import them to the local repository. > - modify, check-in, etc. to your heart's content > - when done, take a copy of the modified local repository files (*,v) back > to your office > - write or find a script or tool that will pull out the changes you've done > on-site, and apply them to the local repository, on a branch created from > the tag in step (1) > - merge changes from the branch to the head > > On subsequent visits, you can re-import the latest version of the > repository, and merge any changes made locally. A viable alternative indeed. Again though, since I don't expect local (not at client site) commits while I'm at the client site, I don't think I should need a branch for each visit. I do tag at both ends of a site visit though. Your approach does allow off-site modifications without collision, which I will keep in mind. > -- > Jim Hyslop > Senior Software Designer > Leitch Technology International Inc. ( http://www.leitch.com ) > Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com "Pray devoutly, but hammer stoutly." --Sir William G. Benham ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
Ok, this will probably seem odd to many on this list, but here goes... On Sun, Apr 03, 2005 at 11:31:01AM +0200, Spiro Trikaliotis wrote: > Hello Doug, > > * On Sun, Apr 03, 2005 at 04:13:24AM -0400 Doug Lee wrote: > > > I very much prefer having the off-site history preserved in the main > > repo, for various reasons. I'll have to think through how important > > that really is though. > > Another option I use many times: > > Before going away from my CVS server, I checkout a sandbox (on an own > branch) on which I want to work, in a directory dir/. After this, I > copy dir1/ to another directory, for example, dir.1/. > > Now, whenever you want to check in something, copy dir/ to dir.2/, > dir.3/, dir.4/, and so on. Furthermore, write the changelog you would > want to apply into a file with a "speaking" name, for example, > changelog.dir.2, changelog.dir.3, and-so-on. > > When you come back home, do the following: > > - go to dir.2, commit and use the changelog file changelog.dir.2 > - go to dir.3, use cvs up, commit and use the changelog file > changelog.dir.3 > - go to dir.X, use cvs up, commit and use the changelog file > changelog.dir.X > > This way, you preserve all the history (in a branch, but at least, you > have it). > > This way, there is no need to fiddle with the CVS repository itself. > > > > Another option, which involves some manual steps but allows you to even > ommit the branch: Do as before, that is, generate dir.1, dir.2, dir.3, > and so on. > > After coming home, diff against the directories (diff -urN dir.1 dir.2 > > 1-2.diff, diff -urN dir.2 dir.3 > 2-3.diff) and put the diffs into > files. Now, go to dir.1 (the original copy), cvs up, and apply the diffs > to the sandbox (patch < 1-2.diff), commit and use changelog.dir.2. Now, > apply the next diff, commit and use changelog.dir.3. As long as there > are no conflicts applying the patches, this works as expected Summary of what I'm about to explain: Most of my projects are actually checked out in a directory with literally up to a thousand files that are not part of the project itself. I'll explain why in a minute, lest I get a lot of "cut that out!" comments. :-) But the upshot is that the above ideas would be rather complex. I actually use CVS on work sites to keep track of exactly which files are and are not part of a given project. For that matter, at home and in my office, I very often have several active CVS sandboxes in the same directory; I just rename the CVS directory for all but the project I'm working on to something else. Obviously no two projects share a file though. Now for why... I write scripts for a screen-reading program called JAWS For Windows (JAWS stands for Job Access With Speech). JAWS scripts must all exist and run in a specific directory, say c:\jaws510\settings\enu. JAWS scripts are named after the applications to which they apply; thus, a script for WordPad will be named WordPad.jss (source code; the compiled version is WordPad.jsb, and there are other associated WordPad.* files as well). Every script for every application that needs special handling goes in the same directory. This is how it comes to pass that I often have multiple simultaneous projects in the same directory with no overlapping file names. Now obviously I could (and sometimes do) create a separate sandbox, copy files back to the live directory as needed, etc. But JAWS comes with a Script Manager--sort of a simple IDE for scripting--and it expects all scripts to be in that same directory... so it's far easier to edit them there than anywhere else. So my typical routine is like this for a new project: Go to a site, make a blank project by an mkdir under CVSROOT, then check out the blank project like this: c: cd \jaws510\settings cvs co -d enu projName cd enu (leave the DOS box open in that directory) Then as I create/modify files, I add them from the DOS box I left active and in the live directory, c:\jaws510\settings\enu in this case: cvs add app.jss app.jsd app.jkm app.jcf cvs commit -m "First recorded version." I thus build up a repository from a sandbox that is literally the live code, committing at the end of a day or when I make a major enhancement or fix, etc. When I'm done, I take the new repo back and plug it into the central master repo for all projects. Next time I visit that site, I take the repo with me from the office and use it to, among other things, detect any changes made since I last left. I plug it in on site like this: Carry it there by zip, unzip into a CVSROOT, make a fresh checkout somewhere else NOT under (in our example) c:\jaws510\settings\enu, then move the resulting CVS directory under that sandbox to be und
Re: Is there a safe way to do this kind of offline CVS management?
On Sun, Apr 03, 2005 at 04:18:48AM +, Pierre Asselin wrote:
> Doug Lee <[EMAIL PROTECTED]> wrote:
> > I use CVS to manage a number of projects. When possible, I use a
> > central repository and link to it either locally or through a tunnel.
> > But sometimes I have to work on a CVS project at a location that has
> > no Internet connectivity. For that, I've routinely carried repository
> > trees around as follows:
>
> > [ snip ]
>
> I check out a sandbox on a laptop and tag it before I leave. I
> take the laptop with me and work without the benefit of CVS (but
> see below). When I return I create a branch off the departure tag
> and update my modified sandbox to it (vacuous update, the just-created
> branch is empty and there is nothing to merge into the sandbox).
> I commit the modifications on the branch. I return to the trunk
> ("cvs update -A") and perform a normal branch merge.
>
> I can work without CVS per se, but I'm really addicted to the
> safety net of revision control, so I use RCS behind CVS' back.
>
> mkdir RCS
> ci -l some_file_I_want_to_hack
> ... hack ...
> ci -l some_file_I_want_to_hack
> ...
>
> When I return, the RCS subdirectories are skipped silently because
> they are in the default .cvsignore . All I have to do is commit
> by modified sandbox to a branch as outlined above.
>
> All the modifications made on the trip are committed as a single
> change without the intermediate history, but this is usually not
> a serious drawback.
I very much prefer having the off-site history preserved in the main
repo, for various reasons. I'll have to think through how important
that really is though.
> Someone, I forgot who and when, posted a gutsy move where a
> sandbox coexists between two CVS repositories.
>
> 1. Commit before you leave.
> 2. Move all "CVS" subdirs to something like ".CVS"
> The cheched-out tree is no longer a CVS sandbox !
> 3. Import into a local repository, created with "cvs init"
> if necessary.
> 4. Check out from the local repository. The resulting
> sandbox has its "CVS" subdirectories but it also has ".CVS"
> subdirectories from the import, with the metadata of the
> original repository.
> 5. Hack normally off the local repository.
> 6. Commit before plugging back into the main network.
> 7. Run a script to swap every "CVS" with ".CVS". What was an
> up-to-date sandbox relative to the local repository is now
> a modified sandbox relative to the central repository, with
> extra ".CVS" subdirectories. (Do not cvs-add these to the
> central repository.)
> 8. Do your "cvs update" and fix the conflicts, then commit.
>
> Once again the entire modification set ends up committed as a unit.
>
> You could even swap CVS--.CVS multiple times and alternate between
> two repositories that way.
I've done stuff like that, but perhaps for a more gutsy reason even:
having one physical directory contain multiple sandboxes for different
projects. The reason I do that would take some explaining, but it's
very common for me to have multiple projects in one directory in which
no two of the projects share a file.
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
BART Group [EMAIL PROTECTED] http://www.bartsite.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Is there a safe way to do this kind of offline CVS management?
On Sun, Apr 03, 2005 at 12:29:48AM -0500, Russ Sherk wrote: Doug Lee <[EMAIL PROTECTED]> wrote: >This process has worked fine except for the occasional issue with >a file being renamed in the repo by something to the same name with >different letter casing, my best solution to which has been a little >hand-editing of CVS/Entries files in sandboxes (despite many >remonstrances against this in a recent thread on this list). Regarding case changes of filenames. What version of windows are you using when the filenames change case? What filesystem is on the thumb drive? I use Win98 and Win XP. Both read the thumb drive, and I never changed the format of the thumb. Not sure what OS one would say is on the thumb drive though. Win98 will sometimes change filenames but NT/2k(3)/XP should not. If it is the latter, I would suggest that it is an application that modifies the filename, not the OS. Windows 98 however, does like to change filenames (FILE.TXT becomes File.txt). There is a checkbox in Explorer->View->Allow All Uppercase file names. I think it's a mixture, but yes, I'm sure an app is to blame sometimes. I don't know what on earth is case-changing directory names though; that's sure inconvenient when the host OS for the repo is a Unix variant... -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com No one alive is beyond hope; every second of life is a chance. (08/29/02) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Is there a safe way to do this kind of offline CVS management?
I use CVS to manage a number of projects. When possible, I use a central repository and link to it either locally or through a tunnel. But sometimes I have to work on a CVS project at a location that has no Internet connectivity. For that, I've routinely carried repository trees around as follows: 1. Tell everyone that they should not modify the central tree, then check out the current HEAD from the tree of interest somewhere at the office so I can use it as a sanity check when I get back. 2. Zip up the tree, take the zip to the work site, and unpack it there into a freshly initialized CVS tree. 3. Work as usual, checking out, modifying files, and committing as needed. 4. Zip up the on-site tree, bring it back to the central server, and use the zip to replace the original tree. 5. Do a cvs update in the sandbox I created in step 1 as a sanity check. This process has worked fine except for the occasional issue with a file being renamed in the repo by something to the same name with different letter casing, my best solution to which has been a little hand-editing of CVS/Entries files in sandboxes (despite many remonstrances against this in a recent thread on this list). This week though, I decided to extend the concept a bit, and I ported a whole raft of things from the central repository over to a thumb drive, then worked on things while on the road. I planned to use `diff' on returning home to detect changed repo files, then drop in the on-the-road versions as needed. I was thwarted, though, by a whole mess of directories whose names had magically become upper-cased on the thumb drive. As a result, what should have taken me some 20 minutes max took hours to straighten out. I know straight CVS does not have support for offline commits etc. and that svk does, but moving from CVS to Subversion or Superversion at this point would be a pretty major undertaking. I prefer a saner method of doing what I do now, within CVS with the inclusion of add-on software if necessary. My ideal situation would be the ability to "check out" a repo tree and leave it locked in the central repo if necessary while I'm gone, make my commits etc., then easily "check in" the modified offline repo tree on returning, without having all this trouble with letter casing in file and directory names. The ability to allow in-office commits simultaneous with out-of-office offline commits would be wonderful, but I don't know how practical that is. A couple details possibly worthy of note: The central server is a FreeBSD box running CVS 1.11.17. The sandboxes are typically created on Windows machines using CVS 1.11.9. (If it will help, I can upgrade the Windows machines to 1.11.17.) I do occasionally make checkouts under FreeBSD or Cygwin, but I never handle a given sandbox with a different OS than the one that created it. I've seen discussion of a commercial CVS replicator on this list but didn't pay close attention. A low-cost commercial package is possible, but an expensive one, or one that is priced per user, is not likely to make it into the picture right now. I doubt a simple use of `rsync' would be sufficient given the letter casing issues I keep hitting. It actually seems like I'm really looking for a CVS for CVS repositories, where my thumb drive or on-site repo copy is a sandbox and the central repo itself is another sandbox that remains always checked out; but the idea of merging changes to a repo file sort of boggles my mind a bit. :-) All advice welcome. Thanks much. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org BART Group [EMAIL PROTECTED] http://www.bartsite.com "Nearly all men can stand adversity, but if you want to test a man's character, give him power." -Abraham Lincoln ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Remote repository permissions best practices
On Mon, Mar 28, 2005 at 04:05:51PM -0500, Todd Denniston wrote: > Todd Denniston wrote: > > > > "Howard, Les" wrote: > > > > > > I've hacked my way through setting up a few CVS repositories in the past, > > > but I've always struggled with getting the user/group ownership and file > > > permissions correct. I always seem to end up with a setup where the users > > > can't access the files that other users have submitted without going into > > > the repository as root and chmod/chowning some of the files. > > > 1) all the users who need write access to the repository should be in the > > same UNIX group. > > 2) after doing `cvs init` you need to chmod g+sw the repository project > > directory, i.e., > > `chown :projectUNIXgroup $CVSROOT/project/; \ > > chmod g+sw $CVSROOT/project/` > BTW, as you currently have a repo, you may need to walk the whole existing > repository tree and do something like: > (assuming no spaces in your directory names, and you use this at your own > risk) > cd $CVSROOT/ > chown :projectUNIXgroup project/ > chmod g+sw project/ > for i in `find project -type d` > do > chown :projectUNIXgroup $i > chmod g+sw $i > done What's the matter with cd $CVSROOT chown -R :projectUNIXgroup . chmod -R g+sw . assuming constant :projectUNIXgroup and no need for different permissions anywhere under $CVSROOT. I wonder in particular if a subsequent reset of owner/perms in $CVSROOT/CVSROOT would be in order. I think -R is standard for both chown and chmod now, but a couple of `man' checks on the target system wouldn't hurt.-- -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Innovation is hard to schedule." -- Dan Fylstra ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
On Mon, Mar 28, 2005 at 02:12:56PM -0500, Jim.Hyslop wrote: > [top posting as a courtesy for Doug] Thanks :) I just hope I don't cause a mess by that comment, which I suppose was fuelled as much by lack of lunch as by anything. :-) > I haven't examined the patch, so I don't know how closely the implementation > matches the proposal, but if I understand the proposed changes, whitespace > is still insignificant, there's just more of it added as a buffer, as an > optimization to improve speed when applying tags. If the implementation is > carried out correctly, then the RCS file will still be compatible with other > RCS-compatible software, some of which could legitimately strip out the > extra whitespace (unless the general practise is to leave whitespace alone). You are correct, according to a message the author just sent me. Consider my complaint dismissed, and thanks for the explanations. > My only concern around this patch is to make sure robustness has not been > adversely affected. I don't know enough about third-party add-ons to know > for sure, or to comment on their use. > > I also like the fact that the change is optional, so that it can be disabled > if any particular platform is incompatible with the changes. > > Doug Lee wrote: > > I have reservations about any system that makes whitespace significant > > in a text file. I can make an exception for indent levels, as used by > > Python, because these are visible and errors are obvious without > > resorting to odd tactics like hex editors, vi's :list command, etc. > > > > I say I expect to be shot down because, of course, the "proper" theory > > is that all in a CVS file is opaque and should not be depended upon by > > CVS users. > > -- > Jim Hyslop > Senior Software Designer > Leitch Technology International Inc. ( http://www.leitch.com ) > Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It is difficult to produce a television documentary that is both incisive and probing when every twelve minutes one is interrupted by dancing rabbits singing about toilet paper." --Rod Serling ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
* don't get rewritten.
+ */
+if ((spaceNeededsymbols_whitespacestart+spaceNeeded+2)symbols_whitespaceend))
+{
+/* looks promising, so the only thing we have to check for now
+ * is block boundary alignment - we aren't going to write
+ * accross a block boundary.
+ */
+off_t firstwritelocation, lastwritelocation;
+
+/* last place to be written is character before the end of the
white
+ * space leaving us one white space */
+lastwritelocation=rcs->symbols_whitespaceend-1;
+firstwritelocation=(lastwritelocation-spaceNeeded)+1;
+
+if ((lastwritelocation/tag_overwrite_blocksize)==
+(firstwritelocation/tag_overwrite_blocksize))
+{
+/* same block */
+do_tagoverwritetrick(rcs,newtagnode, lastwritelocation);
+return;
+} else {
+/* spans block boundary - so we look whether we can pull the
+ * write earlier in the file into the previous block and see
+ * if there is still space.
+ * We need to check that there is still space, also note
+ * that we know that there is whitespace at the start of the
+ * next block so we don't need to worry about that here.
+ */
+off_t oldlast=lastwritelocation;
+lastwritelocation=oldlast-(1+(oldlast %
tag_overwrite_blocksize));
+
+if
((rcs->symbols_whitespacestart+spaceNeeded+1)srcfile, symtag, rev)) != 0)
+newtagnode=NULL;
+if ((retcode = RCS_settag(vers->srcfile, symtag, rev, &newtagnode)) != 0)
{
error (1, retcode == -1 ? errno : 0,
"failed to set tag %s to revision %s in %s",
@@ -1201,7 +1205,7 @@
}
if (branch_mode)
free (rev);
-RCS_rewrite (vers->srcfile, NULL, NULL);
+RCS_rewrite_withtagoverwritecheck (vers->srcfile, newtagnode);
/* more warm fuzzies */
if (!really_quiet)
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
"It is difficult to produce a television documentary that is both
incisive and probing when every twelve minutes one is interrupted by
dancing rabbits singing about toilet paper." --Rod Serling
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Medium sized binaries, lots of commits and performance
You first asked (or at least seemed to want to know :-) ) why performance on a large binary CVS file goes way down when you update from a branch instead of from HEAD. Answer: CVS stores the trunk such that getting the HEAD revision is simply a matter of retrieving a copy of it from the CVS file. To get a branched revision, however, requires the retrieval of the first version in the branch, then all the deltas from then to the revision you want, going forward through branch revisions. I would therefore regard this performance hit as a natural consequence of your use of CVS for binary source code, unfortunately. For a binary file, as you know, a "delta" can be a considerable percentage of the original file size. Your second question was how to remove old revisions in order to improve performance. I don't have a CVS manual URL handy like most participants on this list seem to have, but check out the cvs admin command. It can indeed permanently delete revisions and ranges of them. You could, for example, delete all the revisions from the start of a branch until two or so revisions behind its current state, so as to speed up retrieval of revisions on that branch. Good luck. On Wed, Feb 09, 2005 at 04:37:14PM +0100, Jesper Vad Kristensen wrote: Hi folks, I've searched the net and mail archives for some help or workaround to my problem, but most binary issues tend to deal with the impossibility of diff/merge or whether very large files can be stuffed into CVS. I and the rest of us out here work with Oracle Forms and that means binary source code. At first I was very suspicious of moving to CVS because we were having binary source code, but as it turns out I and everyone else have become extremely happy with CVS. We can't merge, granted, but with our external diff application we reap enormous benefits from using CVS. Even branching is manageable. But here's the problem, especially with our largest 3,5 MB file that's been committed approx. 70 times. When doing a cvs update -r HEAD things work real fast (5 seconds). But if we do a cvs update -r performance drops from 5 seconds to a minute and a half. I can imagine something ugly happening with the "filename,v" file on the cvs server which is 200 MB large. The performance isn't killing us right now, but in maybe 6 months to a year, who knows how bad it may have gotten? So the question is if there are any administrative tools one can use to compress/rationalize/index the file so branch access becomes faster? Is there a way to permanently erase "stuff older than 6 months"? And if not: opinions about my ideas below would be great? My ideas so far: MOVE variant: I wouldn't _like_ to lose the history of the application, but it might be acceptable if performance degrades too much. I figure I could move the filename,v file on the cvsroot repository (to a "backup" folder), then delete from client and add a fresh one and the 1-2 active branches - but can any history be kept if you do this? Will the old history be in the "backup" folder? MIGRATE: An alternative would be to create a new folder (while keeping the old one) and simply migrate _all_ 85 files to the new folder (grab HEAD, add all in HEAD to new folder, grab endpoints on branches, add all branches as I best can). Regards, Jesper Vad Kristensen Aarhus, Denmark ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It is difficult to produce a television documentary that is both incisive and probing when every twelve minutes one is interrupted by dancing rabbits singing about toilet paper." --Rod Serling ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs ignore feature
On Sat, Dec 25, 2004 at 04:07:05PM -0500, Larry Jones wrote: Jeff Decker writes: > > It looks like all the files you put into .cvsignore are to prevent > adding to the repository. No. The sole purpose of .cvsignore and related features is to prevent CVS from constantly reminding you that certain files in your working directory are not under its control. Fine print: It also does serve to prevent ignored files from coming in during a cvs import, which is sorta like keeping them from being added to the repository. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It's not easy to be crafty and winsome at the same time, and few accomplish it after the age of six." --John W. Gardner and Francesca Gardner Reese ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Variable user ID on ssh connection possible?
I have a remote-access issue here. I have a site that has a CVS checkout via ssh on one machine, but the actual developer that sits there is not always the same person. Each developer has a login at the CVS host. The CVS checkout is actually a live environment, which makes it impractical to keep copies for each developer. I want each developer to be able to check out, update, commit, etc., based on his/her account permissions at the server, but I'm having trouble getting CVS to ask for a user ID when a CVS command is issued. I'm rather new to the ssh method of access though, so apologies if I missed something obvious. The approach in effect: - CVSROOT is :ext:[EMAIL PROTECTED]:/path/to/cvsroot - CVS_RSH is ssh (actually c:\cygwin\bin\ssh.exe) - The cvs.exe in use is the stock CVSHome version (not Cygwin's), because we need DOS/Windows line endings here. - cvs checkout works for user "id", but then user "id1" comes along and wants to update the sandbox. I tried setting CVSROOT to just :ext:domain.name:/path/too/cvsroot, but then CVS took my local user name as the user name and wouldn't ask me. In fact, the local user name is the upper-case equivalent of the CVS host's user name, but since the host is Unix, this isn't good enough. Suggestions welcome. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Determine that the thing can and shall be done, and then...find the way." - Abraham Lincoln ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using moving tags
On Thu, Sep 30, 2004 at 11:49:33PM +, Pierre Asselin wrote: > Yamuna Ramasubramaniyan <[EMAIL PROTECTED]> wrote: > > I have a question about using moving tags. You tag > > the repository with LAST_GOOD today. Someone removes > > a file. This file still contains the LAST_GOOD tag. > > The next person checking out the module with the > > LAST_GOOD tag will get this deleted file. Do you use > > a commitinfo trigger to remove the moving tag from the > > deleted file? Are there any other ways to handle this > > case? > > D'oh. I hadn't thought of that. Maybe the tag mover could look > for files that are 1) dead on the trunk, 2) not added on a branch, > 3) still have the tag; and then remove the tag from those files. > Not so easy to do from a sandbox from which the file has been Er...now maybe I'm the one missing something. I don't see the problem: Say the LastGood tag was applied on Monday. Tuesday someone removes a file and commits that, but LastGood is not moved yet. Shortly thereafter, someone checks out via the LastGood tag and, as observed in this thread, gets the removed file. In my view, that is valid behavior; the "good" version contained that file, so out it comes with all the rest. It should not cease to appear with the LastGood tag until that tag is moved further up, past the removal, when the updates since the last tagging are considered "safe." If I understand correctly, removing the file from the trunk will put it in the Attic, so it won't come out when a HEAD checkout is done. I also believe that the LastGood tag is intended to move from its last point to the HEAD periodically when the head is considered "safe." Putting these two things together, I would figure the removed file, though it will technically still contain the tag, will automatically cease to appear in future versions of the system. Now let's see if I'm about to have to take my turn at exclaiming "D'oh." :-) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Pray devoutly, but hammer stoutly." --Sir William G. Benham ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Total Heresy: CVS & Windows MS Office Docs
Re: managing Office files in CVS:
The short answer is yes, but the long answer is no. If I
understand your interest correctly, the answer is definitely no.
Details follow.
Yes, you can store Office files in CVS and get them back out, but you
must tell CVS that they are binary files (-kb on add). You can not
merge versions, get diffs, or pretty much do anything else except
checkin and checkout. Furthermore, CVS will consume vast quantities
of space storing many versions of an Office file because it has no
efficient way of generating deltas between them, and Office files tend
to change dramatically throughout for even small changes in content,
in my experience.
If you just want to version documents, check out the built-in ability
of Office applications to maintain revisions within a single file. If
you're just trying to include Office documents alongside another
project that fits better with CVS, you may find CVS's support
sufficient (I do that much myself). But if you want true version
control of Office files outside of Office's own support, CVS won't fit
the bill.
On Mon, Aug 30, 2004 at 01:56:03PM -0700, Tennis Smith wrote:
> Can cvs be used for change management on Windows Office (e.g. Word/Excel)
> documents? Put another way, can these documents deal with having cvs
> updating them in the repository?
>
> --
> Remove "-remove-to-reply" to respond to my email address directly.
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/info-cvs
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
"Our chief want in life is somebody who will make us do what
we can. {Ralph Waldo Emerson}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Why's it a sandbox?
On Wed, Aug 18, 2004 at 05:28:28PM -0400, Jim.Hyslop wrote: > > Why do people call these "sandboxes"? I'm a professional software developer, > not a kid playing in the sand. > Hehehe...I think "sandbox" is a cool term and never thought of it as at all demeaning. "Sandpit," on the other hand, quickly made me think maybe someone was trying to be politically correct or something. Personally, I much prefer "sandbox" over an overzealous attempt to be PC any day. :-) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "You must let me try, for a true soldier does not admit defeat before the battle." --Helen Keller (in a letter to the president of Radcliffe College) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: /#cvs.lock): No such file or directoryctory for
ice, and the caller will be happy--at least if I fixed the problem... > Cheers > Jim > > > -------- > Email the way you want it - scanned for viruses and unwanted content by emailsystems > > Information regarding this service can be found at www.emailsystems.com > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Believe, when you are most unhappy, that there is something for you to do in the world. So long as you can sweeten another's pain, life is not in vain." --Helen Keller ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branching in a vendor branch
On Mon, Aug 16, 2004 at 06:22:33PM -0700, [EMAIL PROTECTED] wrote:
> I have a project in CVS which is a feature enhancement patch to an
> open source project. My feature enhanced code is checked into the
> trunk. Each major release of the open source project is checked into
> the CVS vendor branch. I have been developing successfully in this
> manner for quite some time now.
I do that too.
> What has happened that is different that I don't understand how to
> handle is the following. The open source project had to create a security
> patch to the last production release. A branch was created off the last
> release tag, and the changes for the security patch were stored in
> that branch. This is where I am a bit lost. I don't see a direct
> way to create a branch within my vendor branch so I can track this security
> patch release.
I don't see why you can't, from a sandbox containing a checkout of the
last vendor branch import (which, of course being a vendor import,
will have a tag and is therefore easy to check out again):
cvs tag -b vendor_release3_security # to create the branch point
cvs update -r vendor_release3_security # to switch the sandbox onto the branch
# copy in the security patch version, which will update files and may add some new ones
# remove any files not present in the security update
# use cvs add and cvs remove to effect those changes in CVS
cvs commit
cvs tag vendor_release3_security1
This method won't give you the ability to use cvs import to get new
security-branch versions, but it will give you what you want otherwise.
Of course your tag naming conventions may differ from my example.
>
> I do see in the CVS documentation you can have multiple vendor branches,
> like the RED and BLUE team examples discussed in 13.6 here:
> https://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_13.html#SEC104
>
> This is not the same as creating a branch within a vendor branch. However,
> I will use this mechanism to track the security patch release in my
> situation, unless someone here can describe a better way to accomplish what
> I am trying so solve.
I think that would work if the security branch doesn't get a lot of
updates, but it would get pretty confusing otherwise, and either way I
bet it would make for some pretty bizarre internal deltas. :-)
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
"The most exhausting thing in life is being insincere."
- Anne Morrow Lindbergh {American Author}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Management of library code in CVS
I have source code files that get used in several different projects (the language does not permit the equivalent of compiled .lib files very easily). It is not common for a project to require a custom-made version of such a file, but it is common for such a file to get updated within a project and then later brought back to a central location for distribution to other projects. I originally thought of using hard or symbolic links in the CVS repository to simplify this problem, but I'm finding there are many dangers to this--unnoticed accidental link breakage, a rogue update breaking things on a company-wide scale, and of course, the joys of a project-specific branch finding its way into a central file. Multiply this last issue a few times, and you have the potential for one truly crazy development tree for a library file! So I'm now inclined to believe that this problem is not better solved by anything other than having multiple copies of each shared file. In this plan, I would have to check occasionally for differences among the HEAD revisions of each copy of each file to find updates, then individually commit those updates to each project. Of course, in branched projects on which development continues along branches, this compounds to include those branches. Is there a better way? I doubt it, but it seems there's no harm in asking. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Sometimes I think my learning curve is a circle." -- David Andrews ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Responding above rather than below largely because my comments are
general thoughts on the whole discussion...
There is wisdom in choosing the right tool for a job. There is also
wisdom in making the best use of the tools you already know and have.
Both can be taken to unpleasant extremes. I believe both extremes can
be "wrong" (from a functional standpoint).
The fact that CVS was designed for mergeable data means it should be
good at that. It does not mean it absolutely cannot serve further
useful purposes. Those who want to use CVS for further purposes would
be well advised to know just what CVS is and is not capable of doing
(note this is not the same as what it was originally designed for, but
rather is what it happens to be able to do reliably).
So for the job of managing versions of mergeable files, CVS bills
itself as ready, and it should do well. For the job of managing
unmergeable files, it sounds to me like it can, regardless of original
intent, as long as you don't go trying impossible stuff. For the job
of managing distribution of file sets among workstations (which may be
on a LAN or across a VPN connection or an ssh connection or whatever
but which do not necessarily have access to a central file location),
I find CVS reasonable.
And may I humbly suggest that, for the job of pursuading the unwashed
masses such as myself of the pitfalls and folly of using CVS for
further purposes than concurrent versioning, information might be a
better tool than inflamation. :-) (Specifically to Greg: The latest
post I saw from you, the one more precisely describing how one might
lay out binary files in directories, manage them with a
version-controlled config file, etc., has made me think more about
this than any other post to date.)
On Thu, Jun 17, 2004 at 06:16:32PM -0400, Greg A. Woods wrote:
> [ On Thursday, June 17, 2004 at 16:25:02 (-0400), Tom Copeland wrote: ]
> > Subject: Re: CVS corrupts binary files ...
> >
> > Hm. Why not simply check these jar files into the repository where they
> > can be tagged/branched/exported and so forth? Why should every
> > programmer on my team need to get all the versions of each jar file laid
> > out on his machine when he could just do a "cvs up" to get the current
> > stuff for his branch?
>
> Don't you have a build system? (apparently you do going by your later
> comments)
>
> Can't it do all those things for you?
>
> Let me repeat: CVS is _not_ a build system.
>
> Just because you can use CVS to update version-controlled files from
> some central repository doesn't mean you should try to use CVS to copy
> all types of files from all kinds of repositories.
>
> If you have many and diverse build machines then put your static
> (i.e. non-changing) components on a central machine in a public
> directory and have your build system invoke the appropriate tool to copy
> them into the build environment as necessary. If you do that, and if
> the way you reference those components includes information about their
> version numbers (e.g. in the name of the directory they're "installed"
> in), and if your build system is configured using normal source files
> (e.g. text makefiles) that you commit to your CVS repository, then CVS
> will track which version of which component is needed for every release.
>
> --
> Greg A. Woods
>
> +1 416 218-0098 VE3TCPRoboHack <[EMAIL PROTECTED]>
> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]>
>
>
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://lists.gnu.org/mailman/listinfo/info-cvs
--
Doug Lee [EMAIL PROTECTED]http://www.dlee.org
Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com
"Our chief want in life is somebody who will make us do what
we can. {Ralph Waldo Emerson}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Multi-branch development without cvslines or temporary insanity
I have a project requiring sometimes up to three branches of development, not counting the trunk, which I use for cutting-edge experimental stuff that doesn't get released unless it works and is then merged onto branches. Often, I have to work on (and commit to) a particular branch, but then I need the update to go to other branches and/or the trunk. The cvslines utility seems to be aimed at easing this precise problem, but it works on the premise that I can apply each commit to all branches at the time of that commit, which would get time-consuming in some cases. Also, the environment here is Windows NT/XP with a stand-alone stock (cvshome) CVS. I'm not sure how easy it would be to put cvslines into this environment. What I'm hoping is that somebody out there has a strategy for simplifying the process of updating one or more branches (possibly including the trunk) from a particular branch (which could be the trunk, AFTER a series of commits have been made to that branch. Is there a popular tagging strategy or some other plan for handling this sort of thing, or is cvslines the best we have? (Cvslines looks pretty cool in some respects btw, notably its ability to delay divergeance until it actually becomes necessary.) This problem makes me wish we could have named commits or commit sets with descriptions, so I could say in effect, "Apply commit-sets 12, 13, and 15 to branch A, commit sets 12 and 14 to branch B, and commit-set 14 to the trunk," where commit-sets 12-15 each consist of one or more specific commit operations (to specific branches). -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com There is more freedom in knowing how to handle pain than in knowing how to avoid it. (4/29/01) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Best way to forward-diff from working copy to HEAD (was Re: strange cvs diff problem with pcl-cvs and viewcvs)
Quick add-on question: On Tue, Jun 15, 2004 at 08:25:14AM -0400, Frederic Brehm wrote: > To see the differences between the local file and the head version you need to > use the command "cvs diff -r HEAD main.f". Any way to reverse that so it's a forward diff, particularly on a whole file set at once? I've been using cvs diff -r BASE -r HEAD [file] but that generates error messages when files have been removed etc., and I wonder if there's a better way. This tactic also seems to fail on branches, though I find "HEAD" seems to have a different meaning sometimes on a branch anyway. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Is your cucumber bitter? Throw it away. Are there briars in your path? Turn aside. That is enough. Do not go on to say, `Why were things of this sort ever brought into the world?'" --Marcus Aurelius ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
ci/co on HEAD for specific files in a branch?
Is there a way for me to specify that certain files should checkout when I checkout a branch but should commit to the trunk when committed? In other words, I have one or more branches that contain a few files that should have only one development path. Specifically, the HTML document describing the project should not branch but should be a part of all branches along with the code. Suggestions welcome. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "You must let me try, for a true soldier does not admit defeat before the battle." --Helen Keller (in a letter to the president of Radcliffe College) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Running standard CVS and CVSNT on the same repository?
Mark D. Baushke wrote: [very nice summary of CVSNT features beyond cvshome (thanks much Mark!) deleted; see below for full messages] > Which features did you need that are not in the CVS > version yet? I just know some clients, notably the CVSNT client of course, say I'd get better results with the CVSNT server. I think the cvs ls command may have been one I'd need, but I also think that's being added to the cvshome version now. The rest of this message is the full context with no further comments from me. On Sat, Jun 12, 2004 at 09:48:02PM -0700, Mark D. Baushke wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Doug Lee <[EMAIL PROTECTED]> writes: > > > Somewhat belated answer here: > > > > I wrote: > > > I run a CVS server on FreeBSD, currently cvs > > > v1.11.5 because that's what came with my > > > FreeBSD installation. I access this server > > > from the same FreeBSD box, from another > > > FreeBSD box, and from an assortment of Windows > > > machines, currently all using standard CVS > > > under Windows. > > > > > > I'm wondering if I can install CVSNT on the > > > server FreeBSD box and start letting Windows > > > machines use that as their server instead of > > > the standard CVS on that box, without causing > > > problems such as repository corruption, > > > incompatible repository changes made by one > > > server and unreadable by the other, etc. I > > > assume I'd be fine suddenly making everyone > > > use the CVSNT server, but then I'd be worried > > > about updates to FreeBSD itself, which might > > > make use of the stock CVS. > > > > On Mon, Jun 07, 2004 at 10:50:43AM -0400, Carucci, Jason wrote: > > > Why not just keep the CVS installation the > > > same on your server and install CVSNT on your > > > Windows machines? This is the setup that I'm > > > using and it works just fine. > > > > I understand that a CVSNT server supports > > features that the stock CVS server does not > > support, and that CVSNT clients use those > > features to great advantage. I therefore figured > > I'd need a CVSNT server to make it worthwhile to > > use CVSNT clients. Wrong? > > There are indeed a few features that are in the > CVSNT server that are not yet in the CVS 'stable' > 1.11.x version and one or two that are as yet > missing from the 'feature' 1.12.x version. (see > http://www.cvsnt.org/wiki/CvsntAdvantages) > > -- "MergePoint" processing > (http://www.cvsnt.org/wiki/MergePoint) > You could use the cvshome version with > more tags to do the same thing, but for > at least some kinds of uses, this is > reportedly a nice feature (I have not > used it myself). > > -- :sspi: authentication (Windows domain > accounts /passwords). This may not > get you much with a CVSNT server running > on FreeBSD. > > -- SSL encrypted :sserver: authentication > (use :ext: with CVS_RSH=ssh for similar > levels of security) > > -- Branch ACLs with 'cvs chacl' and 'cvs lsacl' > instead of being configured via add-on > scripting. > > -- LockServer on a second port replaces > filesystem-based locks & provides file level > locking... Using a LockDir approach with > CVS on a memory filesystem is similar. > > -- More triggers (eg, postcommit) > > -- Supports Unicode files with additional keyword > expansion switches (I'm not sure if you will > need this). > > -- Atomic Checkout behavior (I have not looked closely > at this feature.) > > -- Efficient storage of binary files using > binary deltas. (CVS discourages use of binary > files right now.) > > -- Extended modules functionality using modules2 file > (I have not looked closely at this feature). > > Which features did you need that are not in the CVS > version yet? > > -- Mark > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (FreeBSD) > > iD8DBQFAy9yC3x41pRYZE/gRAnozAKCx28i2XR8Eh3gS3BXWNKnylSaywgCeLawy > wmck3vbZXcr6RnKrOBuf/Qo= > =fh8G > -END PGP SIGNATURE- -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "The U. S. Constitution doesn't guarantee happiness, only the pursuit of it. You have to catch up with it yourself." --Benjamin Franklin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Running standard CVS and CVSNT on the same repository?
Somewhat belated answer here: I wrote: > I run a CVS server on FreeBSD, currently cvs v1.11.5 because that's what > came with my FreeBSD installation. I access this server from the same > FreeBSD box, from another FreeBSD box, and from an assortment of Windows > machines, currently all using standard CVS under Windows. > > I'm wondering if I can install CVSNT on the server FreeBSD box and start > letting Windows machines use that as their server instead of the standard > CVS on that box, without causing problems such as repository corruption, > incompatible repository changes made by one server and unreadable by the > other, etc. I assume I'd be fine suddenly making everyone use the CVSNT > server, but then I'd be worried about updates to FreeBSD itself, which might > make use of the stock CVS. On Mon, Jun 07, 2004 at 10:50:43AM -0400, Carucci, Jason wrote: > Why not just keep the CVS installation the same on your server and install > CVSNT on your Windows machines? This is the setup that I'm using and it > works just fine. I understand that a CVSNT server supports features that the stock CVS server does not support, and that CVSNT clients use those features to great advantage. I therefore figured I'd need a CVSNT server to make it worthwhile to use CVSNT clients. Wrong? -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Is your cucumber bitter? Throw it away. Are there briars in your path? Turn aside. That is enough. Do not go on to say, `Why were things of this sort ever brought into the world?'" --Marcus Aurelius ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS corrupts binary files ...
Is it a proven thing that CVS can corrupt a binary file if no merges are tried and no CR/LF boundary rules are broken? In other words, if I set -kb on a binary file and then do nothing to it but commit updates and sometimes request an old revision, keeping my sandbox in the OS in which it was checked out, could I ever get a bad result? This discussion of binary files has gone on a long time, but either I missed the answer to this, or I never saw it stated. If Greg Woods is reading this, you implied it once in a rather angry message. I welcome the proof, preferably without the anger. On Sat, Jun 05, 2004 at 05:10:58PM -0700, Paul Sander wrote: > >--- Forwarded mail from [EMAIL PROTECTED] > > >Adrian Constantin writes: > >> > >> Or maybe projects for Unix/Linux platforms do not > >> usualy have binary files, but I don't really think so... > > >CVS is a *source* control system; source files are rarely binary. > > I disagree with this statement. Source files are any files that cannot > be reproduced automatically. That is, changes must be made to them > manually using some editor, and that editor need not be the likes of > vi or emacs. MS Word (or Frame Maker) documents, images of various > formats, and documents from various design tools (e.g. GUI builders) > are common examples. > > >It > >does support them as an afterthought, but that's not what it was > >designed to do. > > While this may be true, it turns out that CVS' design can accomodate > such files. Support can be added with a relatively small amount of > effort, which was demonstrated circa Sept. 18, 2001 in this forum in > the form of a patch of the then-current release. All that's needed is > a pluggable diff/merge tool based on the type of data. > > And before someone rehashes the old "you can't replace diff without > breaking RCS" argument, remember that I'm not recommending replacing > the algorithm that computes the deltas. This is strictly a UI thing > in the top layer that is well outside the back-end design. > > >--- End of forwarded message from [EMAIL PROTECTED] > > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It is not the mountain in the distance which makes you want to stop walking; but the grain of sand in your shoe." --Anon ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Running standard CVS and CVSNT on the same repository?
I run a CVS server on FreeBSD, currently cvs v1.11.5 because that's what came with my FreeBSD installation. I access this server from the same FreeBSD box, from another FreeBSD box, and from an assortment of Windows machines, currently all using standard CVS under Windows. I'm wondering if I can install CVSNT on the server FreeBSD box and start letting Windows machines use that as their server instead of the standard CVS on that box, without causing problems such as repository corruption, incompatible repository changes made by one server and unreadable by the other, etc. I assume I'd be fine suddenly making everyone use the CVSNT server, but then I'd be worried about updates to FreeBSD itself, which might make use of the stock CVS. Comments welcome. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Characters live to be noticed. People with character notice how they live." -- Nancy Moser ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Anything out there to help organize all this into a nice repo?
I doubt such a tool exists as what I'm about to describe, but I'd sure love to be wrong. I want to collect a lot of versions of a lot of files into a nice, clean CVS repository, preferably in which the version numbers go 1.1, 1.2, 1.3, etc., instead of using a vendor branch (minor). I do want the commit dates to reflect the file dates of the various versions though, and "cvs import" is the only way I can find to do that without hand-editing the repo files. I want the revisions to go in chronological order. Unfortunately, by now, the various versions of a given file can be in any of the following places: 1. A directory somewhere (we can assume it'll be online and accessible at the time this major process is run). 2. An archive file (zip, generally). 3. Another CVS repository file, because I tried to do this with a bunch of Perl and bat files last December or so but never got finished, and further versions got created since then without CVS being used to manage them... so there are versions in the old CVS repo that got erased out on the network that I'd want to include in this master repository. 4. Any of the above 3 places with a different file name, because some of these things got renamed during their earlier lives. Any versions pulled from a CVS repo (items 3 and 4 above) should keep their log entries, commit dates, and any tags/branches. A tag or branch name should obviously be made to point to the new revision number in the final repo file. Finally, since many copies of a given file may be identical but might not always share the same date/time, the final repo should contain only one copy of such a subset and should have as its commit date the oldest file date found. (I suppose if a CVS version with a log and/or tag/branch names is part of such a subset, the CVS version's log/branch/tag info should be included; but the oldest file date should still prevail if it's older than the CVS commit date found.) Again, I know I'm shooting for the moon here...but if anyone has developed or worked on anything like this, I'm all ears. My December attempt involved running a few home-grown DOS-box utilities to create full-path file lists in chronological order within each name, a lot of global replace commands to reformat the output of that, a Perl script to generate a batch file to runn a lot of CVS and copy commands, and finally a run of that batch file. The batch file generated by the Perl script constructed and cvs-imported N instances of a sandbox, where N was the largest number of revisions found of any single file; thus, each successive import actually made fewer changes, until the last one(s) which might only change one file in the repository. I had to handle the zips ahead of time, and I have no provision at all for pulling stuff from another CVS repo into this one. My Perl script did have a way of letting me group file names into a single set though, so I could deal with case 4 above fairly well (I can't remember how I handled file name upper/lower-case issues though; this is Windows, so case differences in file names should be ignored). Thanks in advance for any info. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "I before E, except after C, or when sounded like A, as in neighbor and weigh, except for when weird foreign concierges seize neither leisure nor science from the height of society." ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Checkout from a Linux-based repository with DOS line-endings
On Mon, May 17, 2004 at 04:55:22PM +0200, Spiro Trikaliotis wrote: > It is no problem to move the repository around, if you don't go across > the border LF/CR+LF. I understand that the repo is always kept in straight LF format, and thus it doesn't matter what the standard is on the machine containing the repository. But it IS important, when transferring a repository, to avoid using an ASCII transfer that could convert line endings in ,v files... -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "No person is your friend who demands your silence or denies your right to grow." --unknown source ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: downloading corrupt .zip files from CVS server
Sounds like maybe you didn't flag the zips as binary (-kb) in your repository? Windows XP would probably try to add CR characters as files are downloaded because Windows uses CR/LF for line endings whereas Linux uses just LF. The rest of this response is not likely to apply, but I'll write it just in case: I've seen one XP system that refused to unpack a .zip file containing actual CVS repository files (ending in ,v). More accurately, it would unpack the zip, but only the non-repo files would show up unpacked; the repo files never came out. I never saw an error message either though, so I bet that's a totally different issue from yours...that and I think you mean "download" to mean retrieving versions, not whole repository files anyway. On Thu, Apr 29, 2004 at 06:11:10PM +0200, joman wrote: > Hi, > > i really hope that someone here can help me. > > I'm using Windows XP verison of Eclipse 2.1.3. and I connect to a remote CVS > server that is run on a Linux type OS. > > Now when I connect and want to download files, all works fine except when > downloading .zip type files. Once downloaded I cant unpack them because I > get told that they are corrupted or something. > > When I do the same connecting from a Linux type System, running eclipse, all > the zip files download fine and all of them work. > > Can anyone help me with this problem? Its really giving me a headache! > > --- jo > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Sometimes I think my learning curve is a circle." -- David Andrews ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
How to unbranch a file?
Please forgive me if I'm missing something obvious... I have a file that was humming along on the main trunk but suddenly needed a branch quite a ways back. I created the branch and committed a few revisions, then some time later figure out how to get the trunk version to work in the branch; so I committed a big revision in which I made the branch copy identical to the trunk copy. Now I'm revising the trunk copy and want the branch copy to keep up automatically. Can this be done, or do I have to keep committing the updates in both places separately? -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com In laughter, love is found; but in tears, it is forged. (12/09/01) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Regarding how deltas are stored in CVS
It was mentioned on another thread that CVS stores the HEAD revision in its entirety, older trunk revisions as backward deltas from the HEAD, and branches as forward deltas from the branch point. If I read this right, a common case will take a lot more space than I thought. My current project is an example: I was just asked to go back and apply some current features to an old revision of a set of files. When I did that, I put in as much of the current code as I could without allowing any code to go in that could have side effects outside those intended. Some files I could literally copy from the HEAD revision (though I did it via the appropriate merge commands); others came close but not quite there, and of course still others remain very different from the head of the trunk. But I think what people are saying is that a copy of the head of the trunk, when placed on a branch, will basically create a reverse-duplicate set of deltas (perhaps condensed into a smaller number of them of course) to the set between the head of the trunk and the branch point. Somehow I'd been assuming that CVS would maybe notice that the head of my branch and the head of the trunk produced identical contents for some files and might only store one copy. I don't yet know enough about the RCS file format, but I wonder if the format itself would support deltas forming a different graph than is currently formed, to optimize file size and/or number of deltas from point to point. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "I before E, except after C, or when sounded like A, as in neighbor and weigh, except for when weird foreign concierges seize neither leisure nor science from the height of society." ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to checkin binary files
On Thu, Apr 22, 2004 at 05:52:17PM +0200, Spiro Trikaliotis wrote: > Specifically for MS Word, I ask myself what would be a better use: Store > the .DOC in CVS, or do the same with the .RTF. RTF is nice because it can be diffed, but (1) I don't always get to choose the doc format, and (2) when you start throwing in pictures, screen shots, etc., an RTF file gets really big really fast... -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com Don't be afraid your life will end; be afraid that itwill never begin. -- Grace Hansen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange "it is in the way" message
On Thu, Apr 22, 2004 at 11:21:03AM -0400, Derek Robert Price wrote: > > Doug Lee wrote: > > >My explanation, right or wrong, is this: I believe the co/update > >command tries to retrieve the file with the case shown in CVS\entries > >AND gets told by the Unix host that there's this new file with the > > > The CVS client should preserve the case of files in CVS/Entries. If > it isn't, that is a bug, but I haven't ever heard of anything like > that before and I've been using both the Windows & Cygwin executables > fairly frequently recently. Oops, I left out a rather important detail: The initial cause of the problem I mentioned is that the case of names in the repo changed. In the thread I started regarding this recently, I explained that I've had occasion to haul a Unix repo off to a remote site and put it under Windows for a while, then bring it back to Unix. CVS uses the same repo format in both OSes, so this works; but Windows sometimes can cause the case of file names in the repo to change, and when those files are pulled back into Unix, the case change locks in and causes the "it is in the way" problem in active Windows checkouts made against them. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Never does the human soul appear so strong as when it foregoes revenge, and dares forgive an injury." --E. H. Chapin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to checkin binary files
On Thu, Apr 22, 2004 at 09:28:09AM -0400, Larry Jones wrote: > Xicheng writes: > Others have already answered your question, but I feel obliged to point > out that CVS was designed for text files, not binary files. You should > carefully consider why you want to put a binary file into a source code > control system. I don't check in compiled versions of my code, but I've had occasion to check in Microsoft Office document files when they're each managed by only one person but accessed by everyone in a group. On one project, where I'm writing code to support specific versions of another application, I've version-controlled various files from their system, some binary, so that I can detect and follow changes in the system I'm keeping up with. Finally, I'm sure anyone who version-controls web sites will want to store images in the repo sometimes. In other words, there are reasons. :) -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Sometimes I think my learning curve is a circle." -- David Andrews ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: strange "it is in the way" message
On Thu, Apr 22, 2004 at 09:04:44AM -0400, Jim.Hyslop wrote: > Lars Huttar wrote: > > On a Windows 2000 server, I'm running > >cvs.exe update -d -P -C > ... > > test server. But for every file that already exists on the test > > server, I get the error, > > > > cvs update: move away > > cocoon/mount/data-server/sources/BPPP.xsp; it is in the way > > C cocoon/mount/data-server/sources/BPPP.xsp > > > > For every file! Whether modified (locally or on the CVS > > server) or not. > > > And most importantly, files that have been modified on other > > machines and committed to the CVS server do not get updated > > (regardless of whether they were modified on the test server). > Now that's really strange. > > What platform and CVS version is your repository? What's your connection > method? I've seen this kind of thing when the CVS server is a Unix variant, the client is in Windows, and the client's CVS\entries file contains file names in a different case than the actual names on the Unix host. The solution for me has always been to manually edit the CVS\entries file on the client and make the case match the Unix host's case for each name--which is, of course, a pain, so I wrote about that issue in a separate thread on this list recently. My explanation, right or wrong, is this: I believe the co/update command tries to retrieve the file with the case shown in CVS\entries AND gets told by the Unix host that there's this new file with the same name in a different case. The first of these succeeds in matching the file also, because CVS translates the case for the transit between operating systems (surely not a precise description of what happens there)... so the upshot is that CVS tries to get the file twice, and the second retrieval collides with the file already gotten and produces the "it is in the way" message. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "It's not easy to be crafty and winsome at the same time, and few accomplish it after the age of six." --John W. Gardner and Francesca Gardner Reese ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Best way to handle this kind of file splitting across a branch merge?
I know this is obnoxious, but here's where I am: I have a trunk with one branch, after which on the trunk, one file splits into about five files. Development of course continued in those five files, but suddenly there arose a need to port selected changes from that development back to before the split. Of course cvs diff is little help, because the file names changed. A simple concatenation of the five files won't work either, because the split was of course more logically than physically guided. I've even thought of sorting lines from both the original file and the concatenation of split files, comparing the results with diff, and using that to identify blocks of code that need to be merged back...but that sounds like a royal mess. An organized set of diffs from just after the split to the present might have helped, except that (1) the splits (plural) didn't all occur at once, (2) a few other changes occurred in commits with splits, and (3) code migrated from time to time among subfiles to reduce coupling between them. The most helpful solution might involve a sorting of code blocks (functions), but that's language-specific and would require coding. Surely this problem is not uncommon. I know Meta CVS handles versioning file names, tree structures, etc.; but even there I'm not sure how I'd go about accomplishing this merge. So my question, more than how to get out of my current pickle, is how to handle such pickles in general, including what preparations, add-ons, etc., to use. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving a CVSNT Repository to Linux.
On Tue, Apr 13, 2004 at 10:35:30AM -0700, Carter Thompson wrote: > > Hi All, > > I'm going to help a friend move his CVSNT repository from Windows 2000 > to Linux. Knowing that we'd like to preserve the history and copy > all the RCS files to the new machine what problems can I expect, > including > line endings (LF,CR). What's the best method of solving this problem? Line endings should be fine because CVS maintains LF endings on any OS. The only issue I foresee is file name case: Windows seems to be a bit careless with the exact case used for file names (or parts of them even). Once you copy your repository to Linux, whatever case is used will be locked in. This shouldn't cause any problems assuming you're not going to try to link an existing checkout to the new location, but you may have a preference as to the case of file names under Linux. If so, you should be able to rename the files under Linux to adjust their case as desired. -- Doug Lee [EMAIL PROTECTED]http://www.dlee.org Bartimaeus Group [EMAIL PROTECTED] http://www.bartsite.com "Innovation is hard to schedule." -- Dan Fylstra ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
"In the way" messages caused by Windows case change
I am using CVS v1.11.5 under FreeBSD as a server (client-server
style). I access this server with a CVS v1.11.5 Unix client and a
v1.11.9 Windows client (the standard cvs.exe, not WinCVS or any
such thing so far). Most projects originate on Windows machines
but can get worked on from either OS, following the "always checkout
and edit on the same OS" rule.
But sometimes I have to work on a project at a site from which I
can't connect to the Unix CVS server. In that case, I take the
Windows CVS client with me, along with a full copy of the relevant
repository tree from the Unix server. I install the tree at the
site in a freshly "cvs init"'d repository, do my work and commit,
etc., then when I'm done, take the updated tree back to the Unix
server and put it in in place of what I originally took to the site.
Since CVS maintains repository files in the same format (no CR at
end-of-line, in particular) regardless of host OS, this seems to
work fairly well... but I am having the following problem with
which I could sure use some help:
I'll have an active project being worked on at a remote site (local
Windows CVS with periodic tree updates to Unix as just described), and
I'll have a checkout from the Unix server that I keep up to date when
I update the Unix tree with the site's tree:
- go to site and work all day
- cvs commit at site to local CVS tree
- send tree to Unix server in a zip
- replace Unix tree with zipped site tree
- go home to active CVS checkout from Unix tree
- cvs update
Occasionally, as a result of Windows changing file name case at the
remote site, the name of a file in the site's version of the
repository changes (only in letter casing). Since I'm replacing
the tree on return rather than adding to or overwriting it, this
does not cause duplicate files. It does, however, cause spurious
"Please move ... it is in the way" messages on the above CVS update
command. The solution seems to be to delete the file causing the
message, hand edit CVS\entries to change the case of the file name
to match the repository, then cvs update to get the file. (What's
happening is that the Windows CVS tries to get the file once with
the old name and once with the new, but the second retrieval runs
into the first file because they match except for case.)
Advice on how to remedy this would be most welcome. I'm
aware that some will probably say I should simply quit using FreeBSD
as a host and stick to Windows; but it is very convenient sometimes
to have the master CVS repository hosted on our FreeBSD server.
For one thing, I can then easily and quickly use the various ports,
such as cvs2cl, to analyze a CVS project. I may still be able to
be convinced to change how the master repository is handled though.
As for the possibility of Meta-CVS, I'm not sure how easy that would
be to incorporate into this dual-OS environment either.
I'm also finding CVS import from Windows issued to a Unix CVS server
can make a mess in the repository when it's onto an existing branch
and file name case changes have happened in Windows, and there seem
to be problems with time stamps in my tree-migration plan when
Daylight Savings comes or goes; but that's for another time I
suppose. :)
Thanks in advance for any help.
--
Doug Lee
Bartimaeus Group
"The most exciting phrase to hear in science, the one that heralds
new discoveries, is not 'Eureka!' ('I found it!') but rather 'hmm
that's funny...'" -- Isaac Asimov
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
