On Fri, Sep 12, 2008 at 12:31:29PM +0100, Julian Foad wrote:
> We won't attempt to apply another update or merge once the
> node is already in some sort of conflict.
Are you really sure about that?
I think we talked about this in the past, and came to the
conclusion that we'd have to allow further merges into
tree-conflicted directories.
There are certain types of conflicts that require an additional
merge to be resolved, such as when a textdelta is applied to a file
which is not yet present in the target branch -- the fix is to
*repeat* the merge with a wider revision range, this time including
the revision in which the file was created on the source branch.
The problem, of course, is what happens when yet another tree
conflict is recorded for the same victim. We currently only
support a one-to-one mapping between victims and conflicts.
But that is more of an implementation detail, right?
Or is there another important reason for this?
If we didn't allow merges into tree-conflicted directories,
people would have to revert -R their working copies, and
then repeat the merge. But if we do that, we're basically
treating the tree conflict as unresolvable.
Unresolvable conflicts would be a totally new concept,
and in a good UI the user would be informed at commit
time that the conflict is not resolvable.
Which implies that we'd need to make a list of unresolvable
tree conflict situations to compare what we find in the
working copy against. Big can of worms :(
> > $ svn update
> > CM foo.c (a file with text conflict and property mod)
> > C dir (a directory containing tree conflict victims)
> > V dir/bar.c (a tree conflict victim)
> > Updated to revision 42.
> > There was 1 text conflict and 1 tree conflict.
>
> Why did you want the notification that 'dir' contains tree conflicts? If
> it's so that you can do a non-recursive status on it and still see
> there's something wrong with it, then wouldn't you want the indication
> to bubble all the way up to the WC root?
>
> I suggest there's no need for reporting 'this contains tree conflict
> victims'.
Yes, agreed. It's redundant and can be omitted.
> > But there is a problem. What if dir/bar.c was text conflicted,
> > had property conflicts, and are also the victim of a tree conflict?
> > Note that such a condition may be the result of multiple updates
> > or merges without conflict resolution done in between.
>
> Let's not allow that. The design we were working to said we would not
> allow that, as I recall. It should bail out if we try to update or merge
> into something that's already conflicted. If that's not done, we'll fix
> it.
I don't think we can simply say "let's not allow that". See above.
> (There's a complication in that the new merge-tracking merges are
> multi-phase and it's not ideal if they bail out after raising a conflict
> on an early phase, but that problem is already present outside of tree
> conflict handling.)
So that's yet another problem with this approach.
> > If we only had 'C' and 'V' and two columns, we could encode
> > this situation as:
>
> I'll follow up with my own proposal.
>
> - Julian
>
I'm waiting in suspense :)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-12 13:58:10 CEST