Stefan Sperling wrote:
> On Sat, Nov 15, 2008 at 10:21:49AM +0200, Daniel Shahaf wrote:
>> Neels J. Hofmeyr wrote on Sat, 15 Nov 2008 at 04:10 +0100:
>>> And the same for merge. Further guidance from `svn info':
>>>
>>> $ svn info trunk/src/com/acme/ui/editors/ColorManager.java
>>> <Info stuff>
>>> <Tree conflict stuff> You have edited file foo but an update tried to
>>> delete, possibly as part of a move.
>>> <In case of D -> M, also show this:>
>>> Hint: This kind of conflict may require `svn revert' to be resolved. Do
>>> make sure that your local modifications are copied somewhere safe first.
>>>
>> I wouldn't mind having this info somewhere (svn resolve --show-suggestions
>> victim_path), but I suspect any kind of "hint" shown by default will
>> eventually get annoying (once I know what it's going to say). Hard to say
>> without having seen it in practice (during my work), though.
>
> The problem is: We ourselves don't even know how to resolve each
> individual conflict in the entire set of possible tree conflicts.
> We've never tried to resolve them all.
>
> I am all +1 on adding some form of guidance to the UI,
> see the "tree conflicts from user's point of view" thread:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=145339
>
> But I think it's a bad idea to start putting hints in the UI without
> having a proper plan mapped out on how we can treat each individual
> conflict scenario, or without knowing whether there is some general way
> that will be able to deal with any possible scenario.
>
> The inconsistencies and weirdness people are seeing in the UI
> are real problems. We have to fix those. So far, most of the tree
> conflicts work was about detection and preventing commits. That
> seems to work fine now.
>
> The 'svn status' interface is still under discussion, and certainly
> a very important part of the UI:
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=14432
>
> Another UI discussion is here:
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142893
> but note how 'svn resolve' is being hinted at but left unspecified at the
> end of that mail (we only ever talked about 'svn resolveD' AFAIK).
>
> I have started walking through some cases in the "tree conflicts from
> user's point of view" thread linked above, just to see what the experience
> is like with the current state of things. I would like to encourage people
> to pick a scenario and walk through it, evaluating how to resolve the
> conflict, for each possible desired merge result if time permits, and
> state what they liked about the experience and what they didn't like.
> Feedback by developers or advanced users who have never concerned
> themselves with tree conflicts before would be most valuable.
>
> I have a couple of scripts that produce tree conflict scenarios to
> work with, so you don't have to make up your own scenarios:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=15317
> You can use these scripts easily if you have a current trunk
> build in your shell's PATH. Sorry, I don't have windows versions
> of these scripts, so you need cygwin or a unix-like OS to run them.
>
> I know it's tedious to walk through these cases, but if we don't
> critically examine and improve our current tree conflicts UI before
> release and end up shipping the release with a bad UI, my intuition
> is that people will complain as badly as they are complaining about
> the current merge-tracking problems in 1.5.x.
>
> We can use a lot of users over this if we don't get this right.
You mean "lose".
Yes, I agree. I'm seeing some parallels to the bad experiences described in
Hyrum's paper that was recently posted to the committers list. It feels like
we are again defining 1.6 as "the release that can handle tree-conflicts",
while we are at a point in time where tree-conflicts should ideally be
stable (as of last Wednesday), but instead we're stumbling across newly
discovered bugs (and even a design flaw once) on a pretty much regular basis.
We might well be able to stabilize tree-conflicts stuff in a matter of
weeks. Then again, we might not! That would mean we are repeating 1.5, while
everyone was saying "we *must not* repeat 1.5".
Needless to say that a bunch of people (probably including my employers)
would be awfully pissed off if tree-conflicts didn't make it into 1.6. But
what about the big rest of Subversion use, at large?
Should we maybe think of a Plan B? What parts of tree-conflicts handling
could just be disabled so that 1.6 becomes stable without removing
tree-conflicts altogether?
What are your views, everyone...
~Neels
Received on 2008-11-16 02:17:25 CET