[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.
> 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. Do you think we should add conflict
resolution interactivity to update as well?
>
> 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? ;)
> 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 know this is not being implemented right now, but I suggest we drop
> > the talk about interactivity from the specs.
>
> For the reasons above, i disagree.
>
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. If someone can design a good plugability interface that
can allow customizing this behaviour, then I am for that.
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 08:51:40 2007