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.
We want to make it easier for people to move files and directories
around to do refactoring, not harder.
Stefan
---------------------------------------------------------------------
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-15 13:54:08 CET