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

[Bo Berglund]

There is no conflict.
A conflict occurs when two files that are being merged have *different* 
changes to the same part of the file (=same line). If the differences 
are on different parts of the file the merge just combines them and the 
result contains both informations.

In this case you are merging an empty file (the delete one) and a file 
with contents (from the branch) and obviously there are no conflicts at 
all here. The merge just enters the full contents of the branch file as 
the new contents of the HEAD file and is happy to see that there was not 
a single case of a line with changes on both files....

/Bo

-----Original Message-----
From: Mike Lehmann [mailto:meiklehmann at gmx.de]
Sent: den 3 september 2003 10:43
To: cvsnt at cvsnt.org
Subject: Re: [cvsnt] No conflict when merging, where one is expected


> 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
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt