Re: Maintaining branches...

[Paul Sander]

This is all true.  The "from" version is usually specified by the user with
a -j option.  The "to" version is the one in the user's workspace.  The
reference version can be given with a second -j option, but by default it's
the version at the intersection of the branches that include the "from" and
"to" versions.

One of the annoying results of this is that when the same two versions are
merged several times, the results of prior merges show up as merge conflicts
when the default reference version is used.  The workaround is to commit the
results of each merge and apply a label just to identify it as the reference
for the next merge.

If CVS had and equivalent to ClearCase' merge arrows, then a more intelligent
choice could be made for the reference version, reducing the distances of the
diffs and eliminating the needless conflicts.

--- Forwarded mail from address@hidden

On Wed, Jun 13, 2001 at 10:25:18PM -0400, Ralph Mack wrote:
> Maybe the term "merge" is ambiguous. My concept of a merge is:
> 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.
> Does CVS use a different merge concept entirely? 

Not quite, but close:
0. select a reference version and a from and to version
1. make a diff from the reference version to the "from" version
2. apply the diff, as a patch, to the "to" version

They don't even have to have a common ancestor.  It can be any two
versions, and really, in any order (example, maybe you want to back out a
specific set of changes on a particular branch).

--- End of forwarded message from address@hidden