Neels J. Hofmeyr wrote:
> 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...
>
I think it is *always* better to say, "sorry, we couldn't do this in the
time available", rip out an unstable feature, and roll 1.6 with the
other improvements already on trunk; than to have to keep apologizing
for either delaying the release, or shipping a crap implementation.
With 1.5 and merge tracking, it appears we did both. :)
So I suggest: disable tree conflicts (if that means branching trunk
again and physically ripping out the code, that's fine); and release a
stable 1.6.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-16 02:59:20 CET