Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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