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

[Cameron, Steve]

Derek Price wrote:

> Linus Tolke wrote:
> 
> > I want a note in the (cvs)Merging adds and removals also. That is where
> I
> > look if I want to know how the handling of added and removed files is
> made
> > when you merge branches.
> > [snip]
> 
> Okay, I took Linus' advice to heart.  Comments anybody?
> 
> Derek
> 
        [smc]  Hmm, interesting.  I think the first time I saw this 
        thread I didn't fully understand it.

        I can see *why* one might want to use a single static tag.  One
might want to do
        something like this:

        cvs rtag -r branch_tag merge_point everything
        cvs update -j merge_point

        The idea being, that if you did this, instead:

        cvs update -j branch_tag
        cvs rtag -r branch_tag merge_point everything

        Then, there is a possibilitye that "merge_point" does not
        actually correspond to what was merged in the case that
        someone checked something in on the branch between
        those 2 operations, whereas, the first sequence would avoid
        that possibility. (but run into the problem this thread alludes to,
        namely that removals won't be handled right because dead revisions
        won't have the static tag, if I'm understanding this right.

        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:

                   Note that the handling is slightly different depending
upon
                   whether one or two join targets were specified.  If two
                   join targets were specified, we don't check whether the
                   file was modified since a given point.  My reasoning is
                   that if you ask for an explicit merge between two tags,
                   then you want to merge in whatever was changed between
                   those two tags.  If a file was removed between the two
                   tags, then you want it to be removed.  However, if you
ask
                   for a merge of a branch, then you want to merge in all
                   changes which were made on the branch.  If a file was
                   removed on the branch, that is a change to the file.  If
                   the file was also changed on the main line, then that is
                   also a change.  These two changes--the file removal and
the
                   modification--must be merged.  This is a conflict.  */

        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.

        BTW, I don't recall seeing any mention of the above subtlety in the
        manual...but I might have missed it.

        So If i'm understanding all this right, I don't see any solution
that is
        completely satisfactory...

        I guess the most satisfactory way to do it is:

        cvs update -j branch_tag
        cvs rtag -r branch_tag merge_point,
        while simultaneously disabling checkins (perhaps by a means
        as simple as shouting down the hall "ok, nobody check in anything
        until I say it's alright.")

        -- steve
>