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/foo.c_at_2
> Source right: (file) file:///tmp/trunk.EKH/repos/branch/foo.c_at_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
Received on 2010-05-05 20:27:01 CEST