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 1.9.6.1 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