On 05/03/2010 10:25 PM, Daniel Näslund wrote:
> On Mon, May 03, 2010 at 03:07:49PM +0200, Neels J Hofmeyr wrote:
[...]
>>> stat->lock_creation_date = 0;
>>> + stat->conflicted = (tree_conflict != NULL);
>>
>> I don't understand -- what about prop and text conflicts? Below,
>> ->conflicted stands for all three of them.
>> (If this is correct, I guess it needs a comment)
>
> Added a comment in r940600. AFAIK, the only scenario where we can get a
> conflict on an unversioned node is for an incoming delete to a locally
> deleted path. (It will be troublesome to fit that case into the idea of
> storing tree conflict info on the node instead of its parent).
ah, ok, that makes sense. Shouldn't be trouble to store such tree-conflict
in the ng-ACTUAL tree? ...but, thinking aloud a little:
The entry can't be NULL for a schedule-deleted node (asked for with
show_hidden == TRUE). Analogously, the wc-ng tables do have both ng-BASE and
ng-WORKING nodes for a locally deleted path.
So, if there is no metadata in the WC on the node, there can't be *any*
(tree-)conflict on it! Right? Let's see:
Another case: obstructed; there is no metadata in the WC, but a file/folder
sits at a path. Say update wants to put something at that path: it'll create
a base node (above theory holds -- TC needs to have metadata).
Ok, furthermore, say merge wants to put something there, at the obstructed
path. It'll create a working node that is added (obstructed_add). Again,
there is a WC metadata entry.
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.
* neels attaches the test script
Is this the real justification why there could possibly be a tree-conflict
on an entry==NULL node?
> Thanks for your review,
heh, I'm glad I can say some intelligent stuff, too. Usually it was Julian
telling me about my patches in much the same way. :)
~Neels
Received on 2010-05-05 11:38:15 CEST