> 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.
I just want to throw in my personal experiences:
In (most) conflict cases, I cannot use interactive merge tools at all:
In most cases, for resolving the conflicts, I really need my Visual
Studio editor, I need the compiler, I need to run tests etc.
I think (at least for me) the best workflow would be:
while(true)
{
svn merge;
if(no conflict)
break;
resolve conflicts using all your development tools;
}
This assumes that the merge command works atomic:
A revision is either merged into all files, or in no file.
Otherwise you cannot test your merge.
BTW, in unfortunate cases, resolving conflicts may require days.
In other words, I really WANT to type "svn merge" multiple times:
Once per conflicting revision.
BTW, personally I hate interactive command line programs.
They remind me of modal UIs at the times of MS-DOS. See also for example
http://en.wikipedia.org/wiki/Copy-paste#Comparison_to_verb-object_paradigm
;-)
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 29 09:38:31 2007