Daniel Rall writes:
> > For example,
> > early in the locking feature design discussions, interactivity was
> > proposed to resolve locking conflicts, but that was decided against later.
>
> I appreciate the example and history, though, don't find this specific
> case to be a particularly relevant comparison. When compared to
> merging, locking is a brief and trival operation, especially once
> Merge Tracking comes into play.
>
This was only meant as an example of an earlier attempt to introduce
interactivity that was rejected. However, the similarity is that the
update command, in the locking case, would go from non-interactie to
interactive (except for the initial authz question). We didn't want
it to wait in the middle of an update.
> > The exceptions are related to authentication (asking for username and
> > password), certificate handling and of course invokation of external
> > editors and diff/merge programs.
>
> Okay. Invocation of external merge programs is a very relevant
> comparison, and one where my research shows our existing
> implementation to be woefully insufficient in terms of usability; an
> external merge tool will currently be invoked for every merge (over
> and over), rather than only for conflict handling (the use case for
> the merge conflict resolution callback).
>
I am mostly concerned with default behaviour. If users deliberately
enables some "plugin" that makes the client interactive, then that's
by intention, I guess.
> > 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...
>
> Yes, this is a nice property of Subversion, which as spec'd would be
> preserved even with the addition of interactive merge conflict
> resolution in the command-line client by use of the --non-interactive
> flag (or API equivalent).
>
Having to use --non-interactive meas that we change the default to be
interactive. Problem is that --non-interactive is a one-or-nothing
knob. As I see it, --non-interactve is primarily meant for scripts.
> > If people want interactivity, then can create their own wrapper
> > scripts or use more GUI oriented clients.
> >
> > I know this is not being implemented right now, but I suggest we
> > drop the talk about interactivity from the specs.
>
> As no one is working on this, and I do not intend to complete more
> than an API for 1.5.0 (at most), how about rewording the spec to
> describe the interactivity as a possible (pluggable?) behavior,
> possibly available via your Subversion configuration?
>
Heh, the let's not make the decision now approach;)
Some pluggable behaviour is fine by me. As I said, I am concerned
with the default behaviour. And I don't think that the possibility of
pluggability in the future should impact our usability now. (Not
claiming that anyone said that, jut making sure my point gets
through). That's why I want the repeated merge scenario, making
merges restartable, to work as good as possible even between commits.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 25 14:21:23 2007