Re: Is there a safe way to do this kind of offline CVS management?

[Doug Lee]

On Sun, Apr 03, 2005 at 04:18:48AM +0000, Pierre Asselin wrote:
> Doug Lee <address@hidden> 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           address@hidden        http://www.dlee.org
BART Group         address@hidden   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)