RE: Maintaining branches...

[Thornley, David]

> -----Original Message-----
> From: Ralph Mack [mailto:address@hidden
> Sent: Wednesday, June 13, 2001 10:52 PM
> To: address@hidden
> Subject: Re: Maintaining branches...
> 
> 
> [Quoth I... :-)]
> > 0. select a reference version and a from and to version
> > 1. make a diff from the reference version to the "from" version
> > 2. make a diff from the reference version to the "to" version
> > 3. merge the diffs (preferably with optional user input), and
> > 4. apply the result to the "to" version.
> 
> As I lay in bed thinking about all this, it suddenly occurred to me 
> that, since CVS is always using the root as its reference version, 
> CVS (and its ancestor RCS) can get away with not recalculating any 
> diffs at all during an update but merely selecting from among the 
> diffs calculated during prior commits. This is a significant time 
> savings. A commit becomes the only operation that actually 
> calculates a diff as a side-effect.
> 
CVS does not always use the root as its reference version.  The
restriction is not that CVS does not permit merging, but that
it does not itself have an automatic way of keeping track of
what has been merged where.  The user can keep track of this
information with a tag, or externally, or can just merge the last
change (which is usually what you want to do anyway).

A commit is not the only operation to create a diff; the "cvs diff"
command will normally also do so (although that diff is not
kept by CVS; if you want to keep it as a diff you can save it yourself).
For example, "cvs diff -r 1.10.2.6 -r 1.12.6.3 foo.C" will create
a diff between the version of foo.C in two different branches.
(If you like, "cvs update -r 1.23.2.3 foo.C; cvs update -j 1.10.2.6
-j 1.12.6.3 foo.C" will attempt to apply the difference between
1.10.2.6 and 1.12.6.3 to 1.23.2.3, which is usually not a useful thing
to do.)

> Is this true? If so, it seriously restricts the kind of merge 
> behavior that CVS can support, but I can see why it was done. 
> Lots of other things about CVS that seemed a little odd also 
> suddenly become comprehensible.
> 
It restricts the kind of merge behavior that can be done without
further ado and record-keeping.  It does not restrict the ability
to arbitrarily merge if the user is willing to keep track of things
in some way.  We use a tag to show what has been merged already.

> How hard is it to extract three different revisions of the same 
> file to a temp area outside of the normal checkout tree using 
> CVS?

If I were going to do that, I'd do three separate "cvs update -r ..."
commands, moving each to the appropriate directory after the update.
Again, it is not something that CVS automatically does with a simple
command out of the box.

 (I'm contemplating what a seperate graphical merge utility 
> layered on CVS might need to do.)

If I were to use this approach in order to use a different merge I
would write a script to do it.  There is certainly no reason why it
can't be done, but for most purposes CVS's merging is quite adequate.