[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.
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.
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? (I'm contemplating what a seperate graphical merge utility
layered on CVS might need to do.) This approach would be slow,
of course, as it would have to extract and diff twice for every
file in the covered area to determine if there is any work to
do for each one. The result of the merge would be copied back
to the checkout tree.
By the way - step 4 should have read "apply the result to the
reference version" (not the "to" version). I'm going back to bed. :-)
Ralph A. Mack
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs