[cvsnt] Re: BUG when merging and removing files on branches

Kevin zzz at zzz.zzz.org
Fri May 7 07:20:49 BST 2004

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.

"Tony Hoyle" <tmh at nodomain.org> wrote in message
news:ibgk909hd40b4e5dk9vlbdj65pgif00vo3 at 4ax.com...
> On Thu, 6 May 2004 09:17:25 +0200, "Kevin" <zzz at zzz.zzz.org> wrote:
> This isn't a bug, it's a conflict.
> You have edited a file, and another branch has deleted it.  There is
> no safe resolution other than report this and expect the user to
> handle it.
1) There was no conflict reported!
2) I did not edit the file on both branches, I edited the file on the trunk
only and deleted the file on the trunk. On the branch there were no edits.
Thus the merge should be able to cope with the situation. In fact if I
merged once after the delete only, the file would be scheduled for removal
correctly on the branch. As far as I understand the process, if there are no
edits on the branch, the merge should always reflect the changes on the
trunk including deletes.

> If it deleted it, then that would be a bug.
I agree with you provided that there were edits on the branch other than
merges from the trunk.

> Tony

Can CVS check if the file *contents* are identical when doing a merge? What
I mean is that in the scenario described revisions that corresponds
to revision 1.10 (its mergepoint) are identical. Thus CVS can detect that
the only changes from 1.10 to 1.11 (file deleted) have occurred on the trunk
and can safely be applied to the branch.

Am I missing something in this reasoning?

Kevin Agius

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook