On 1/24/07, Peter Lundblad <plundblad@google.com> wrote:
> Hi,
> But then there is talk about adding this interactiveness to the
> cmdline client, which I don't like...
>
> We've tried hard to keep the client as non-interactive as is
> reasonable even when --non-interactive is not specified. For example,
> early in the locking feature design discussions, interactivity was
> proposed to resolve locking conflicts, but that was decided against later.
>
> The exceptions are related to authentication (asking for username and
> password), certificate handling and of course invokation of external
> editors and diff/merge programs.
>
> 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.
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.
I believe this is the right behavior for interactive mode, and in
--non_interactive mode, i would make it stop after applying all
non-conflicted merges, and let the user take care of the rest.
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.
Personally, i've never started a merge and then went and got coffee.
I start merges when i'm ready to deal with merge conflicts.
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.
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 would support --non_interactive only performing merges it can do
without asking the user for anything.
Your proposal only supports those users who want to go get coffee,
and penalizes those who want to deal with the merge right now. OTOH,
i suggest that mine does the right thing by both sets of users. Those
who want non-interactive merges should use "--non-interactive"
> 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.
>
> Regards,
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 29 01:59:43 2007