[PATCH] Re: Interactive conflict resolving in the cmdline client

[Peter Lundblad <pl...@google.com>]

Daniel Berlin writes:
> On 1/29/07, Peter Lundblad <pl...@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.
]]]

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Folker Schamel <sc...@spinor.com>]

> Folker Schamel writes:
>> Peter Lundblad wrote:
>> Does you mean the following:
>> File A may have conflicted by merging in r1000,
>> and r2000 is never merged in.
>> File B successfully has merged in r1000 and r2000.
>> Is this correct?
>>
> Yes.
> 
> 
>> But usually, r2000 of A and r2000 of B need each other.
>> This means, if you manually have resolved the conflict in file A,
>> then you cannot compile and test your work,
>> because B includes r2000, but A does not include r2000 yet.
>> Is this right?
>>
> 
> You can't sometimes, so you need to restart the merge where it left
> (note that this is all done in a local WC without commits in
> between).  But the question of interactive or not doesn't change that,
> does it?

They are separate issues, but they are related to each other:

I just think it is very important that for resolving merge conflicts
the user is not restricted. Often the user needs all his development
tools (editor, compiler, automated test, manual tests etc.) to fix a conflict.
In the same way as today the user often needs to use all his development
tools for fixing classical update conflicts.

To make this possible, this requires a working copy having
no mixed revisions. And, as second aspect, GUI callbacks
are too restrictive for using all your development tools.

Cheers,
Folker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Peter Lundblad <pl...@google.com>]

Folker Schamel writes:
> Peter Lundblad wrote:
> Does you mean the following:
> File A may have conflicted by merging in r1000,
> and r2000 is never merged in.
> File B successfully has merged in r1000 and r2000.
> Is this correct?
> 
Yes.


> But usually, r2000 of A and r2000 of B need each other.
> This means, if you manually have resolved the conflict in file A,
> then you cannot compile and test your work,
> because B includes r2000, but A does not include r2000 yet.
> Is this right?
> 

You can't sometimes, so you need to restart the merge where it left
(note that this is all done in a local WC without commits in
between).  But the question of interactive or not doesn't change that,
does it?

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Folker Schamel <sc...@spinor.com>]

Peter Lundblad wrote:
> Daniel Rall writes:
>> On Fri, 09 Feb 2007, Peter Lundblad wrote:
>>
>>> Daniel Berlin writes:
>>>> On 1/29/07, Peter Lundblad <pl...@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.
> 
> We have to stop merging the particular file, but we can still continue
> merging the rest of the tree, ignoring the conflicted files and
> keeping track of that in the merge tracking info.

Does you mean the following:
File A may have conflicted by merging in r1000,
and r2000 is never merged in.
File B successfully has merged in r1000 and r2000.
Is this correct?

But usually, r2000 of A and r2000 of B need each other.
This means, if you manually have resolved the conflict in file A,
then you cannot compile and test your work,
because B includes r2000, but A does not include r2000 yet.
Is this right?

Cheers,
Folker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Daniel Rall <dl...@collab.net>]

On Fri, 09 Feb 2007, Peter Lundblad wrote:

> Daniel Berlin writes:
> > On 1/29/07, Peter Lundblad <pl...@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 @@
>  <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>

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Peter Lundblad <pl...@google.com>]

Daniel Berlin writes:
> That said, since we appear to disagree about this, why don't we start
> as you suggested (noninteractive), and if there is as much a backlash
> as i expect, we change it.
> (IE we note that we may change the default depending on feedback,
> rather than setting it in stone like we normally do)

That's the intention of the patch I already committed, yes;)

Also, I hope this is not set in stone already, because then we are in trouble.
We are still talking about the merge command which has been in svn
since long before 1.0...

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [PATCH] Re: Interactive conflict resolving in the cmdline client

[Daniel Berlin <db...@dberlin.org>]

> 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'm pretty sure this will end up being the new #1 complaint about merging.
At least among my users.
That said, since we appear to disagree about this, why don't we start
as you suggested (noninteractive), and if there is as much a backlash
as i expect, we change it.
(IE we note that we may change the default depending on feedback,
rather than setting it in stone like we normally do)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org