Doug Lee <[EMAIL PROTECTED]> 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 _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs