RE: Documentation suggested to clearer state restrictions to merg ing removed files

[Cameron, Steve]

Derek Price wrote:

> "Cameron, Steve" wrote:
> 
        [smc]  [..snip...] 
> >         So that brings up a third alternative, using a (previously
> created)
> >         tag to mark the origin of the branch, (or my ".origin" patch
> that I
> >         keep harping on about now and then) and two -j options:
> >
> >         cvs rtag -r branch_tag merge_point everything
> >         cvs update -j branch_fork_static_tag -j merge_point
> >
> >         But this has another problem, namely that file removals will
> >         be handled *without possibility of conflict*... according to
> >         the comments around line 2177 of update.c (cvs 1.11)
> >         which say:
> 
> [snip]
> 
> >         And when I first came across that, it seemed like a bug, but the
> >         more and more I thought about it, considering especially that
> the
> >         two -j options can refer to *any* two revisions, I'm convinced
> that
> >         what the comments say here is the correct way.
> 
> Can you provide me with an example of when this might be the desired
> behavior?
> 
        [smc]  Consider a reverse merge to roll back a bunch of changes.

        cvs update -d -P -j newer_tag -j older_tag

        Suppose some file was added between older_tag and newer_tag.
        The reverse merge should remove that file.

        "unless there's a conflict", you say?

        Well, how can you tell if there's a conflict?  What are
        you going to use for the common ancestor so that you
        can know what changes have been made since that
        common ancestor in the code that's being merged
        into, and thus know that this reverse merge conflicts with
        those changes?  You can't just assume that "newer_tag" makes
        sense as a common ancestor.  

        It gets stranger, because the code you're merging
        into could conceivably be from a completely different
        branch on which "newer_tag" and "older_tag" don't
        even exist.

        That's the problem, in the general case,
        with two -j options, there's _is_ no common ancestor.

        It might be cool if you could use _four_  -j options, to tell CVS
        something like:

        CVS, please merge the changes between A and B into this code, 
        and BTW, please calculate any conflicts versus the changes 
        between C and D, like, "cvs update -d -P -j A -j B -j C -j D",
        or, I suppose "D" is superfluous, as it should be the code
        that's being merged into, so maybe just "cvs update -j A -j B -j
Ancestor"
        with the 4th one being implied as the code that you've got sitting
in your
        sandbox..

        I'm not sure that such a "4-way merge" really makes any sense
though, 
        or if its even possible, or if it does and is, how one would even
attempt it.

        Don't count me as any kind of expert on any of this...

        -- steve

>