Hi,
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.
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...
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.
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.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 24 22:10:15 2007