[techtalk] Write down while you are modifying the system...

Malcolm Tredinnick malcolm at commsecure.com.au
Wed May 2 22:16:43 EST 2001


On Mon, Apr 30, 2001 at 10:03:02PM +1000, Mary Gardiner wrote:
[...snip...]
> btw can anyone give me a run down on this situation:
> 
> X outside project (say an open source project) has a cvs tree. I want
> to be able to import their CVS tree, whilst at the same time
> maintaining my own tree, probably minor, of changes, and resyncing
> every so often.

I read the other replies in this thread and they may give the facility
that Mary is after. However, CVS also includes a "natural" way of doing
this sort of thing: vendor branches.

Vendor branches are generally useful when you receive some third party
sources from time to time and would like to make local modifications of
them in your own repository. So any commits you make go to your own tree
(the vendor never sees them unless you send them a patch).

Suppose you have a third-party project call Project X. I'll assume that
you've just done something like "cd ProjectX; cvs update" and have a
version you wish to import into your own repository. Further, let's
assume that you haven't already made changes to Project X.

What follows is pretty much a step-by-step guide. If the steps are
already obvious, I apologise in advance. It's all fairly
straightfoward -- the only real magic is in steps 4 and 5.

The first few steps are just like putting some sources into CVS for the
first time on any project.

(1) Get the Project X sources ready for importing. This means removing
anything that looks like a CVS directory. Failure to do so will confuse
the local cvs program no end. So ...

	cp -a ProjectX Temp
	cd Temp
	for file in $(find -name CVS); do rm -rf $file; done

(2) Now import the sources into your local repository. At this point
there is a small decision to be made. You probably want the local
sources to appear in the directory ProjectX on checkout. But you already
have a ProjectX directory (the third party CVS copy). So I would
probably move the existing ProjectX directory to something like
ProjectX.orig (you want to keep it around to periodically update and
resync with the local copy). To do the importing...

	cd Temp
	cvs -d /home/CVS import -m"Initial Project X sources" ProjectX \
	  ProjectX_vendor ProjectX_1_0

(I'm assuming that /home/CVS is your local repository. Change it as
appropriate.)

The three words after the import comment (the -m argument) correspond to 
	(a) The module name (ProjectX). This will be the "natural"
	directory it checks out into.
	(b) The vendor tag -- set to something sensible. This is the
	name of the vendor branch as a whole.
	(c) The release tag. This will be the thing that changes each
	time you re-import some new ProjectX sources to resynchronise.
	So either set it to a release number, or maybe something like
	the date. Just remember that it's a normal CVS tag, so you can't
	use decimal points, for example, in the tag name. The release
	tag corresponds to a particular point on the vendor branch (to
	mark where the import occurred).

(3) Now you can remove the Temp directory and, assuming the original
ProjectX sources have been moved aside, just do

	cvs -d /home/CVS checkout ProjectX

and start applying your local changes, committing willy-nilly and
generally having a good time.

So far, everything like normal. Now comes the cool part ... merging with
a later version of ProjectX.

Suppose time has passed and you have recently updated ProjectX.orig and
noted that things seem to have changed enough that it's worth
resynchronising with the local copy (more normally, the vendor has just
delivered a brand spanking new release of their product to you and you
want to put it into the local tree).

(4) We just re-import the ProjectX.orig sources as before, but with a
different release tag...

	cp -a ProjectX.orig temp
	cd Temp
	for file in $(find -name CVS); do rm -rf $file; done
	cvs -d /home/CVS import -m"Merging with ProjectX" ProjectX \
	  ProjectX_vendor ProjectX_2_0

At this point cvs will probably tell you that some conflicts were
created by this import (and possibly even suggest a command to resolve
them).

(5) Now you have to resolve the conflicts. One thing to note here is
that the previous step will probably have reported more conflicts than
actually existed, so don't panic about the possibly large amounts of
work involved yet. :-)

	cd ~/ProjectX
	cvs update -j ProjectX_1_0 -j ProjectX_2_0

This just updates your tree, merging all changes in the branch
containing the ProjectX_2_0 tag into your current (main) branch, but
only starting at the ProjectX_1_0 tag (since you already have the
changes up to that point).

Wanrings: If you leave out the first tag here, too many changes will be
applied, possibly overriding your work. Secondly, if you get the tags in
the wrong order, cvs will diligently try to patch up to the _1_0 tag,
beginning with the _2_0 tag (i.e. like applying a reverse diff). This is
sometimes useful for undoing changes, but in this particular case it's
plain bad and will lead to trouble and much hair pulling and teeth
gnashing.

At this point in the show you will have some files that are just
modified (all the changes were merged successfully with yours) and some
that are in conflict. The previous step was probably quite verbose
(even if you use the '-q' flag to CVS), so I usually do a "cvs -q
update" at this point, just to find out what's changed. The modified (M)
files get committed straight away (with a comment that the changes were
merged) and then I go to work on the C (conflict) files.

-----------------
OK .. that all looks terribly complicated in retrospect, but it's not
really. After the initial import, the reimporting and merging becomes
fairly natural.

For the last few months I've been using a vendor branch to manage my
linux kernel sources, since from time to time I've been applying patches
that weren't in the Linus or Alans' trees and just generally playing
around. CVS was great for managing everything and keeping track of
changes and the vendor branches meant I could always track the current
state as well.

Cheers,
Malcolm

--
How many of you believe in telekinesis? Raise my hand...





More information about the Techtalk mailing list