[cvsnt] No conflict when merging, where one is expected

Mike Lehmann meiklehmann at gmx.de
Wed Sep 3 09:43:27 BST 2003


> This is not in fact a conflict - a conflict would be when you two
> changes cannot be resolved - in this case you have deleted the file
> from the trunk then merged in a new file from the branch and it
> behaves as expected - the branch takes precedence as there is no
> longer any file on the trunk to conflict with.

Well, the task of merging is to automatically merge changes made in a 
branch into the current branch. If CVS cannot do it automatically, it 
creates a conflict. Since in this case, it cannot merge the change 
automatically, because the file was deleted (quite the same as I would 
have removed all lines from the file), it MUST produce a conflict. CVS 
cannot decide, that the change is obsolete, only the user can this. 
Otherwise CVS just ignores changes on merge, which is IMHO very dangerous.

--Mike


On Tue, 02 Sep 2003 15:30:31 +0100, Tony Hoyle <tmh at nodomain.org> wrote:
> On Tue, 02 Sep 2003 16:14:13 +0200, Mike Lehmann <meiklehmann at gmx.de>
> wrote:
>
>> Hi,
>>
>> I create a branch-tag for a file. Then I remove (and commit) it on the
>> main trunk. Now I checkout the branch, modify the file and commit the
>> changes. When merging the changes of the branch into the main trunk, no
>> conflict occurs, although it is expected.
>>
>> The described situation happens, when we actually move files in the main
>> trunk (larger refactoring), but want to get conflict, that need to be
>> solve manually in the moved file.
>>
>
> This is not in fact a conflict - a conflict would be when you two
> changes cannot be resolved - in this case you have deleted the file
> from the trunk then merged in a new file from the branch and it
> behaves as expected - the branch takes precedence as there is no
> longer any file on the trunk to conflict with.
>
> Tony


More information about the cvsnt mailing list