On Wed, 24 Jan 2007, Peter Lundblad wrote:
...
> The merge tracking func spec talks about the problem of conflict
> resolution when the svn client splits a single merge of a revision
> range into subranges to avoid repeated merging. There is the plan for
> an API to give library users a chance to resolve conflicts
> interactively before merging the next range. This is completely fine
> by me.
Cool! And thanks for reviewing the specs, Peter.
...
> We've tried hard to keep the client as non-interactive as is
> reasonable even when --non-interactive is not specified.
I too like this fact.
> 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.
> 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 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).
> I don't see why conflict resolution should change just because we
> devide the merge into several operations. We can mark the object as
> conflicted, the user can resolve the conflict afterwards and retry
> the operation. Since we track what files were merged and what
> revisions, there shouldn't be a problem of repeated merging in the
> working copy.
With the very recent addition of handling for sub-tree merge info by
Kamesh (which you pointed out has some editor API usage problems which
still need to be worked out), this becomes a possibility. Previously,
we've had no mechanism for suppressing the merge of paths of the
change described by a revision range.
> 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?
Implementing this behavior as an external program is somewhat
difficult, and leaves us little better off in terms of interface
between Subversion's libraries and the conflict resolution mechanism
than we are today with the external merge tool.
- application/pgp-signature attachment: stored
Received on Thu Jan 25 00:00:30 2007