Re: Tree conflicts - how's it going?

On Fri, May 23, 2008 at 03:48:15PM +0100, Julian Foad wrote:
> [RECORD]
> ========
>
> Status: complete enough to use.
>
> Primary APIs:
>
> To do:
>
> * APIs for getting a human-readable description are here in libsvn_wc,
> but should be moved to a higher (client) layer.

I thought clients were free to call the working copy lib?
If so, why do we need to duplicate the API in the client lib?
Otherwise, +1 on providing interfaces to these calls at the client layer.

> [DISPLAY]
> =========

> To do:
>
> * Design: conceptually, do we want to see conflicts on the parent directory
> or on the victims?

There is no status column left to show tree conflicts on files.
Unless you make it print something else, like 'T' (which we did
at some point in a very early implementation IIRC), users won't
be able to tell whether a 'C' in the first column is a text conflict
or a tree conflict.

For directories, this is not an issue, because so far, they could
only have property conflicts, i.e. only the second column was used.

> * Clean up the "svn info" text: make it much less verbose.

If you want to do that, OK.

> * Move the human-readable data up from libsvn_wc to libsvn_client or so
> - see [RECORD].

The human-readable data being the "svn info" text before or after
making it less verbose?

> * Consider whether "svn st ITEM" should show conflict on victim ITEM.

We had it print the human readable description at some point.
Right now, it shows only a 'C' on directories containing tree
conflicts. But this information is rather terse. Maybe printing
a 'T' instead of 'C' for tree conflict victims would be a good
idea. But what do we do with files that are both tree conflict
victims and have text conflicts? Should we print 'T' until the
tree conflict is resolved, and then 'C'?

>
> [COMMIT]
> ========
>
> Status: incomplete
>
> When parent and victim are included: complete?
> When only the parent is included: complete?
> When only the victim is included: incomplete

Also, the issue addressed by the double-delete branch needs to
be resolved, otherwise commits succeed in use case 3 if the
user does not run update before commit.
 
> To do:
>
> * Make commits fail when tree conflicts exist, even when the victim's parent
> is not part of the requested commit.

Hmm, I never noticed this bug before. +1 on fixing it.

> [RESOLVING]
> ===========
>
> Purpose:
>
> Provide the user with tools and information and to resolve the conflicts.
>
> Notes:
>
> * Not sure what's needed here.

In this section, you refer to interactive conflict resolution, right?

I'm not sure about the details either.

To be able to resolve tree conflicts with the interactive conflict
resolution feature, I guess we'd need some predefined set of possible
ways of resolving each type of tree conflict. If we had that, we could
prompt the user and offer some choices. But if there was any tree conflict
for which the fix isn't in a known set, we'd have to ask the user to
resolve the conflict manually.

> [RESOLVED]
> ==========
> Issue #3144 <http://subversion.tigris.org/issues/show_bug.cgi?id=3144>

I believe you meant #3145 -- "svn resolve[d] should be aware of all the
different types of conflicts"

http://subversion.tigris.org/issues/show_bug.cgi?id=3145

> To do:
>
> * Design: conceptually, do we want to "resolve" the parent directory or
> the victims? Due to what falls out of the early implementation, we were
> heading for a concept of resolving the parent directory... but I don't
> feel that's right. See also [DISPLAY].

Yup, the current implementation of "resolved" was a quick way
of getting some way of resolving in place. It was primarily intended
for testing. It needs finer granularity as explained in issue #3145.

Note though that the current resolve code clears text and property
conflicts no matter what. So in this regard, we are consistent with
the current (but lacking) implementation :)

> * Ensure the basic "resolved"/"resolve --accept=" works on a whole directory.
>
> * Allow individual victims to be marked as "resolved".

Maybe something like:
        svn resolve --type=tree dir/victim
The default (and possibly only value that makes sense) for --accept
would "working" in this case.

If --type was not specified, it would be equivalent to:
        svn resolve --type=text dir/victim

And for consistency, this should also work:
        svn resolve --type=prop propname dir/victim
The extra propname argument is ugly cause it's inconsistent with
the others, but we can't get away without it, can we?

Well, well, I guess I'd better leave this one to qualified UI
designers...

Stefan