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

[Pierre Asselin]

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.

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.

-- 
pa at panix dot com