On Fri, 09 Feb 2007, Peter Lundblad wrote:
> 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.
...
> 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.
In merge-tracking land, because we have to stop merging after the
first unresolved conflict is encountered, the "go and get your coffee"
approach simply doesn't work.
> > > This means that, to have a reasonably consistent UI, update should
> > > be interactive by default as well.
...
> 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.
Yup, 'update' will likely need to grow a merge resolution callback as well.
> > > 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.
...
> > > 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?
A lot of cherry picking would aggravate this use case. In the
branching models I deal with on a day-to-day basis, heavy cherry
picking is the norm.
...
> 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.
Looks fine for now, +1.
> [[[
> * 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 @@
> SCM automated merge
> 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>
- application/pgp-signature attachment: stored
Received on Sat Feb 10 04:05:05 2007