[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is there a safe way to do this kind of offline CVS management?
From: |
Doug Lee |
Subject: |
Re: Is there a safe way to do this kind of offline CVS management? |
Date: |
Sun, 3 Apr 2005 06:16:52 -0400 |
User-agent: |
Mutt/1.5.6i |
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 address@hidden http://www.dlee.org
BART Group address@hidden 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