info-cvs
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]