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 under c:\jaws510\settings\enu. I then run `cvs diff' to detect changes, then make any necessary commits and start from there and work as I described earlier. The RCS idea recommended earlier by Pierre would help here I suppose, but it still seems more cumbersome than CVS for what I'm trying to do. Copying the directory each time in my case, as suggested above, would also be cumbersome because I would then have to keep splitting the files I need out of the ones I don't, or make absolutely huge file sets needlessly every time. My current approach seems to work very well as long as nothing (be it app or OS) recases file and/or directory names, but those recasings sure are a pain sometimes... -- 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