Stefan Sperling wrote:
> 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?
Clients are free to call the WC lib. They don't want to receive pre-formatted
descriptive text from it. I think they want to receive structured data which
they can interpret themselves in order to make decisions on it, and to present
the data to the user in any way they choose. If we think it is worth giving
them the ability to convert it to "standard" or "default" human-readable text,
we can provide a client-layer function to do that.
It's the client library's job to provide a client-oriented view of both the WC
and the repository and the interactions between them. Although conflicts happen
only in the WC, I still think it is the client's job (aided by the client
library) to provide a higher-level view of what goes on in the WC, and the WC
library should not try to do this presentation of data itself.
> If so, why do we need to duplicate the API in the client lib?
I'm not proposing duplication. The WC lib should manage the WC and supply data.
The client lib should help the client to process and present that data.
> Otherwise, +1 on providing interfaces to these calls at the client layer.
>
>
>>[DISPLAY]
>>=========
>
I'll reply separately about this topic of how to display the information.
>
>>[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.
Yes. Issue #3156 <http://subversion.tigris.org/issues/show_bug.cgi?id=3156>.
I've just added the keyword "tree-conflicts" to it.
>>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.
:-)
This is related to the philosophical question, "In a tree conflict, is it the
victim that is in conflict, or the parent that is in conflict, or both?"
>>[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?
Well, I wasn't very clear about what this section is about. Actually, I meant
this section to be about selecting and/or merging the two conflicting changes,
and I meant the following section "[RESOLVED]" to be about telling Subversion
that you have done so. Interactive resolution does both of those things. I'll
change it so there's just one section about resolving.
> 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.
Yes.
>>[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
I mentioned both of those issues.
>>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...
I'll start a new thread on that.
Thanks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-28 13:00:38 CEST