Neels J. Hofmeyr wrote on Sat, 15 Nov 2008 at 04:10 +0100:
> Hi tree-conflicts fans!
>
> (Thanks for the update, Mark. Looks a lot better now, doesn't it.)
>
> I think it would be nice to the folks out there to sort of tell them what to
> do a little more. Following Mark's example, I put myself in a frame of mind
> of not knowing anything much about Subversion. As a newbie, I would never
> have guessed to use 'revert' to resolve my conflict. I would have resolved
> it, then gotten the conflict again, tried to `resolved' again, and started
> to panic, trying to just remove it from disk and stuff.
>
> How does this look:
>
> > $ svn up
> > C trunk/src/com/acme/ui/editors/ColorManager.java
> > A trunk/src/com/acme/ui/editors/MyColorManager.java
> > U trunk/src/com/acme/ui/editors/XMLTagScanner.java
> > U trunk/src/com/acme/ui/editors/XMLEditor.java
> > U trunk/src/com/acme/ui/editors/XMLConfiguration.java
> > U trunk/src/com/acme/ui/editors/XMLScanner.java
> > Updated to revision 4.
> > Summary of conflicts:
> > Tree conflicts: 1
> <In case of tree-conflicts, also show this:>
> Hint: Use `svn info' to get more information on tree conflicts.
^
'svn info VICTIM_PATH'
>
> 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.
Daniel
> $ svn ci -m logmsg
> <msg> foo remains in conflict.
> <In case of tree-conflicts, also show this:>
> Hint: Use `svn info' to get more information on tree conflicts.
>
> $ svn resolved foo
> Resolved conflicted state of foo
> <In case of D->M conflict, 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.
>
> One might argue that `svn resolve' will be the catch-all resolver for
> tree-conflicts in future. But I think I would be confused as a new user. I
> myself actually used to be confused about "resolve" and "resolved" not being
> the same thing. So I don't want to expect all those users to know which
> command to use when, and that `resolved' may not help at all, that `resolve'
> may be the proper thing to use, but until it's implemented to use `revert'
> sometimes. Gah!
> Even when `resolve' works properly, it would be nice to hint at `resolve'
> and prevent people from getting stuck with `resolved' -> `update' ->
> `resolved' -> ... without knowing alternatives.
> So, me as a dummy newbie, I want to be guided in the right direction
> whenever I encounter these what? Tea-convicts? ;)
>
> What do you guys think?
> ~Neels
>
>
>
---------------------------------------------------------------------
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 09:22:46 CET