Daniel Berlin writes:
> On 1/29/07, Peter Lundblad <plundblad@google.com> wrote:
> > Not exactly, since the conflict might actually be blocking further merging.
> > And if/when we get atomic moves, it might be necessary to do merging
> > in revision order to get things right.
>
> Yeah, but it would already be in the right order.
> That's why it's not stored in some unordered form.
> You know what revisions you will have to apply after the conflict is
> resolved, since they are in the queue.
>
> I'm not sure what you think the problem is. I've seen this implemented
> before, so i'm positive it works :)
>
What I mean is that if you merge file a and because of chery-picking, the merge
gets split into a few pieces, then in the first merge, you get a conflict
and wait for the user. The user makes her choice. Then you have to do
the rest of the merges which might take some time and the user has to wait.
>
> >
> > > This is actually the approach i greatly prefer. If you go to get your
> > > coffee, the merge will be as far along as it can make it without human
> > > intervention, and will nicely be ready for you to help it fix the
> > > rest.
> >
> > This means that, to have a reasonably consistent UI, update should
> > be interactive by default as well.
>
> Why do you think it means this?
>
Because both commands can cause conflicts as a result of tree merges.
I think it is a bit inconsistent if one command asks the user what to do and
the other doesn't.
> > Do you think we should add conflict
> > resolution interactivity to update as well?
>
> No, merges are not the same as updates.
>
I'd say they are, it is just a question of which trees are merged.
> > Why so? It is the exact same command. It should be in the shell's history,
> > shouldn't it? ;)
>
> Oh brother. Do you also think that because your shell can substitute
> variables that we shouldn't have a shorthand to referring to the repo
> root?
>
Not at all. That's a different question.
> These types of little annoyances make users really hate a tool after a while.
>
We have lots of situations where the user gets asked to fix something, add
the --force flag etc. and then restart the operation.
I haven't seen lots of people being annoyed by that, but then it is some time
since I was on the users@ list.
> > I continue to believe that we should be consistent in our UI and let users
> > deal with conflicts after the command is finished, and possibly have to restart
> > the merge command.
>
> I'm sorry, but i don't see this as a good thing. GCC merges to
> branches are often touching the same file hundreds of times. I don't
> want to have to type svn merge two hundred times because it has
> decided to quit every time it sees a conflict.
>
If you merge revision ranges when possible, how can it be that a merge
touches a single file hundreds of times normally?
> > If someone can design a good plugability interface that
> > can allow customizing this behaviour, then I am for that.
>
> So how do you propose to cater to the users (which are clearly not
> some minority, for the sake of argument, let's say it's 50-50 either
> way) who just want to run svn merge once and deal with the conflicts.
>
As I said in the paragraph you quote, I'm fine with a plugin interface for
this that could be enabled.
> We already have an option that means "make things non-interactive". If
> you want non-interactive behavior, use it.
>
No, because that's a one-or-nothing option.
So, since we don't seem to agree on what the default behaviour in the
cmdline clinet should be and since we aren't implementing for this in 1.5
ayway, I propose that we just soften the wording as in the attached
patch. Then we at least don't make a commitment to change the default
merge behaviour in the future.
[[[
* svn/trunk2/www/merge-tracking/func-spec.html
(conflict-resolution): Soften the requirement for interactive
conflict resultion in the command line client.
]]]
Index: www/merge-tracking/func-spec.html
===================================================================
--- www/merge-tracking/func-spec.html (revision 23369)
+++ www/merge-tracking/func-spec.html (working copy)
@@ -352,11 +352,12 @@
<a href="requirements.html#automated-merge">SCM automated merge</a>
use case.</p>
-<p>The command-line client supplies a default merge conflict
-resolution callback which will behavior much like <em>svk</em>, when
-in interactive mode displaying some context for each conflict and
-prompting for how to resolve it, or when in non-interactive mode,
-taking directives beforehand (<i>unimplemented</i>).</p>
+<p>In a future release, the command-line client may supply a
+merge conflict resolution callback which will behave much like
+<em>svk</em>, when in interactive mode displaying some context for
+each conflict and prompting for how to resolve it, or when in
+non-interactive mode, taking directives beforehand
+(<i>unimplemented</i>).</p>
<p>Related discussion from the dev@ mailing list can be found
here:</p>
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 9 15:45:37 2007