On 1/29/07, Peter Lundblad <plundblad@google.com> wrote:
> [Removing merge tracking tag from this subject, since, when thinking about it,
> it isn't really relevant to merge tracking only.]
>
> Daniel Berlin writes:
> > On 1/24/07, Peter Lundblad <plundblad@google.com> wrote:
> > > I think this is a good thing and a property of our client that we
> > > should strive to reserve. You can start a merge, possibly type in a
> > > password, then go for a coffee and not come back whatching the client
> > > waiting for a response...
> >
> > Well, there is a way to do both, actually.
> > You can do all the merges you can without requiring responses, and
> > queue those that turn out to be conflicted until the end, and then be
> > interactive.
> >
> 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 :)
>
> > 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?
> Do you think we should add conflict
> resolution interactivity to update as well?
No, merges are not the same as updates.
>
> >
> > I originally believed the behavior of being interactive would be
> > annoying, but after using svk, hg, and perforce, i see it as a good
> > thing.
> >
> Interestingly, after using perfoce for a while, I still find it being
> interactive to be annoying, so that's clearly a matter of taste;)
>
> > I also *know* most of my users would be seriously annoyed if they had
> > to type svn merge > 1 times in order to complete a merge.
> >
> 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?
These types of little annoyances make users really hate a tool after a while.
>
> > Giving interactive mode the least amount of interactive behavior that
> > doesn't require you to type svn merge multiple times (which is what i
> > believe the above is) seems right to me.
> >
> I don't understand this requirement. I don't find it worse than sometimes
> having to do svn commit, svn up (possibly in a loop) to resolve
> out-of-dateness.
I do.
svn up is not going to cause conflicts for me most of the time.
> 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 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.
We already have an option that means "make things non-interactive". If
you want non-interactive behavior, use it.
If you want to make it the default, i'd be annoyed, but i'd probably
set a ~/.subversion/config option that would be nicely provided to
make it not the default and just go about my way.
I really don't think we should provide *nothing* to users who want to
do interactive merging and conflict resolution.
Not the least of reasons that it would affect me :)
>
> Thanks,
> //Peter
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 29 15:45:01 2007