[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 04:13:24 -0400 |
User-agent: |
Mutt/1.5.6i |
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)