[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One working copy part of two repositories?

From: Eric Siegerman
Subject: Re: One working copy part of two repositories?
Date: Tue, 20 Feb 2001 16:45:13 -0500
User-agent: Mutt/1.2.5i

On Mon, Feb 19, 2001 at 05:50:10PM +0100, Stefan Bellon wrote:
> At first my questions seems to be strange and sounds like nonsense.
> That's why I will elaborate on the task I want it to do:
> Imagine you're porting a big program from one platform to another. The
> main tree of the program is already held in CVS. So I check out a
> working copy from this main repository.
> During the porting I want to have full control over my changes in a
> local repository so that I can step backwards if something breaks, etc.
> So I import it into my local repository.
> But now I have a problem w.r.t. the CVS directories in the working copy.
> Is there any way of synchronising such a development? Please don't
> suggest to use the main repository as this is no option. I'll have to
> use a local one, but later on I want to check in the changes into the
> main repository -- when they're stable.

You should create a branch in the main repository to hold your
porting work.  Ideally, you could do the work directly on this
branch, and only merge once the sources were stable.  I'm not
sure why you consider this not to be an option, since it won't
impact on others until it until you've finished your port, and
are ready to merge the results back into the mainline -- that's
what branches are for, after all.

But if there are other reasons you can't use the main repository
(eg. the machine which hosts it isn't visible to the one where
you'll be doing your work), do the following.  You'll still
create a branch in the main repository at the beginning of the
port; but the branch will sit idle until final-merge time.

In the following, upper-case names are my symbolic names for the
various things you'll be working with.  For convenience, =FOO=
marks the name's definition.  I'm assuming that the port is to be
done on a machine not visible from the CVS server, and have thus
included non-CVS copying steps.  Steps flagged with "*" are done
on the CVS server, or a client CVS-visible from it.  Those
flagged with "-" are done on the porting machine.  Those flagged
with "?" are the copying steps between the two machines; if my
assumption is false, these steps are unneeded.

Initial preparation:
  * In the main repository =REPOS-MAIN=, create a branch
    =PORT-BRANCH= for your porting work
  * Check out a new sandbox =SB-MAIN= on PORT-BRANCH
  ? Copy SB-MAIN to the machine where you'll do the porting work
    (use tar and ftp, floppy disks, or whatever)
  - Make a copy of SB-MAIN; call it =EXPORT-SOURCES=
  - Delete all the CVS metadata from EXPORT-SOURCES:
        find . -type d -name CVS -print | xargs rm -rf
    (Don't take the obvious shortcut of just using "cvs export";
    later, you'll need the unmodified SB-MAIN)
  - Import EXPORT-SOURCES into your own private repository,
  - Check out a sandbox from REPOS-WORK; call it =SB-WORK=
  - EXPORT-SOURCES is now junk; you can safely delete it

Now do your port in SB-WORK, committing to REPOS-WORK at will.

When you're ready to merge back into the main repository:
  - Make backups of both SB-MAIN and SB-WORK!  I can't stress
    this enough -- in case something goes wrong (which it may
    well do), you'll *need* virgin copies with which to try
  - From SB-WORK, delete all the CVS metadata (see above "find"
  - From SB-MAIN, delete everything which is NOT CVS metadata.
    Perhaps something like this will do, but be careful:
        cd SB-MAIN
        find . -type f -print | grep -v '/CVS/' | xargs rm
  - Recursively copy (what's left of) SB-WORK over top of (what's
    left of) SB-MAIN
  - Now, SB-MAIN contains your modified sources, but with CVS
    metadata appropriate to the original, unmodified sources on
    PORT-BRANCH in the main repository REPOS-MAIN, as of the
    beginning of your porting work
  ? Copy this merged SB-MAIN back to the machine on which it was
    originally checked out
  * In SB-MAIN, "cvs add" and "cvs rm" any files that need it
  * commit (recall that this is to PORT-BRANCH; your changes are
    still not visible to people working on the mainline)
  * Using REPOS-MAIN, do a vanilla merge from PORT-BRANCH to the

I haven't done all of this, but I've done a subset: working
disconnected without bothering to create a REPOS-WORK, ie. with
my working sources not CVS-controlled.  This subset of the above
recipe consisted of the steps flagged with "*" and "?"; on the
remote machine, I just worked in the untarred SB-MAIN (complete
with CVS metadata appropriate to REPOS-MAIN), then tarred it up
again when done.  But my disconnected sandbox was still given its
own branch.


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)

reply via email to

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