On Wed, 2008-08-20 at 17:32 +0200, Stephen Butler wrote:
Hi Stephen. Thanks for the feedback.
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
> >> * subversion/svn/schema/status.rnc
> >> (attlist.wc-status): Add a flag for the whether a directory has tree
> >> conflicts.
> >> ### Want to change this to per-victim flags.
>
> There's a UI design issue here,
Well, the issue you're commenting on is the non-XML status output.
I am assuming we will show something like "CC" for a tree conflict, the
same as if there were both a text and a property conflict. Note that an
object can:
(have a text conflict and/or a property conflict)
or
(be the victim of a tree conflict)
at any one time.
> due to a lack of space in the user
> interface. The output of 'svn status' (in this branch) prints 'C' in
> the first column of a directory's status if it contains tree conflict
> victims. For a file victim, 'C' in the first column is already used
> for text conflicts.
>
> There is a priority for use of that first column, in the case that
> more than one status applies to an item. Obstructed/missing/incomplete
> and added/deleted/replaced are higher priority than a text conflict.
> Only modified is lower. (see libsvn_wc/status.c)
I don't think a text conflict can be produced on an item that is
obstructed or missing or incomplete or deleted, so talking about
relative priority is meaningless. (What you see in status.c is just a
hidden implementation detail.) For a text conflict produced by "svn
update" on a replaced file, an experiment I just did found that 'C' was
displayed in preference to 'R', and after I marked the conflict resolved
then 'R' was displayed again.
> I think a tree conflict should have a higher priority than added et al.,
> because we want a tree conflict to block an update, switch or merge
> operation (when not using --force). We want to make it obvious that
> the tree conflict exists.
Yes, something like that.
> Perhaps even a higher priority than
> obstructed et al., though I'm not sure of that yet.
(Again, that's meaningless as we won't allow "tree conflict" and
"obstructed" to co-exist.)
> Also, we need to choose a letter. T and C are already in use. How
> about E?
Like Mark said, E is in use too, but I can't see much problem with using
"C" for either sort of Conflict. There will still be the concept of the
four versions of the file (or directory): merge-left, merge-right, mine,
working. The difference is just that, with a tree conflict, some of
those versions might be nonexistent. OK that's not the _only_
difference, but it is a largely similar situation.
> With per-victim flags, the output of the update, switch, merge, info
> and status commands would have to change, as well as these .rnc files,
> the function svn_wc_conflicted_p2() in libsvn_wc, etc.. I'm sure we
> can handle these details after we sort out the UI issue.
Yes.
This does show that we need a "Tree Conflicts UI" design/spec document.
> (I'll add a few comments about tests, too, in another mail.)
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-08-21 23:10:01 CEST