On Wed, May 05, 2010 at 11:37:09AM +0200, Neels J Hofmeyr wrote: > Ok, even furthermore, say there is nothing, absolutely nothing at WC path > foo.c, and I do a two-URL merge. The URL I merge from has foo.c on the left, > but no foo.c on the right. So technically, the merge should want to delete > foo.c in my WC, where it never existed in any way. (I never thought about > this before!) How does merge handle that? > > * neels writes a test script > > [[[ > [foo.c never existed on trunk, and r3 deletes foo.c on unrelated branch] > + svn merge -c3 '^/branch' trunk/ > --- Merging r3 into 'trunk': > C trunk/foo.c > --- Recording mergeinfo for merge of r3 into 'trunk': > U trunk > Summary of conflicts: > Tree conflicts: 1 > + svn info trunk/foo.c > Path: trunk/foo.c > Name: foo.c > Node Kind: none > Tree conflict: local delete, incoming delete upon merge > Source left: (file) file:///tmp/trunk.EKH/repos/branch/fo...@2 > Source right: (file) file:///tmp/trunk.EKH/repos/branch/fo...@3 > > + svn status trunk > M trunk > ! C trunk/foo.c > > local delete, incoming delete upon merge > Summary of conflicts: > Tree conflicts: 1 > ]]] > > Good grief, another hole in tree-conflicts! It says it was locally deleted > and status '!', but it never existed locally. It should rather say something > like... er... 'missing' doesn't really hit home either. 'local void, > incoming delete' ?? Do we need another conflict_reason to flag this? > Resolving this automatically would definitely need different behaviour than > a truly locally deleted node or truly missing node.
What it should really be doing is realise that the node never existed in the branch and so deleting it is not a conflict (I know svn is not that smart yet and won't be for a while...) But I think the missing status notification is just fine in the meantime. I agree the text should say "local missing" instead of "local delete", but IIRC we don't know the difference since we're not searching branch history [yet]. Stefan
