On Fri, Feb 15, 2013 at 01:12:49PM +0000, Philip Martin wrote:
> The way move-update works is that an update that attempts to change a
> move source raises move-away-edit tree-conflicts on the move source.
> The user resolves those conflicts to transfer the changes to the move
> destination. The process of transfering the changes may raise further
> move-away-edit conflicts if there are nested moves, and the user
> resolves those in turn. So to fully update a move the user must keep
> choosing 'mine-conflict' until all the move-away-edit conflicts are
> resolved.
>
> The problem is that other conflicts can be raised: text-conflicts,
> property-conflicts and tree-conflicts like delete-edit. The user may
> not want, or even be able, to resolve these as 'mine-conflict'. So in
> practice the user has to make a decision on each conflict. In most
> cases I suspect what the user want is a:
>
> resolve all move-away-edit as mine-conflict and leave all the others
>
> option.
>
> To further complicate the UI it is possible to have moves inside
> deletes, and moves inside deletes inside moves. The move-update code
> handles these and can still transfer the changes to the move destination
> but doing it involves resolving the delete-edit tree-conflicts as
> 'working. So now I suspect what the user wants is a:
>
> resolve all move-away-edit as mine-conflict and all delete-edit as
> working and leave all the others
>
> option.
>
> How do we make the UI work?
I think we should provide high-level options that do the right thing
in the given situation. The purpose of the tree-conflict resolver is
to offer pre-defined resolution strategies, which would otherwise be
too complex or cumbersome to be performed in individual steps,
especially for inexperienced users.
The user should say "Apply the update to the moved node" and Subversion
should examine the state of the move source and target and then
automatically decide whether this means "resolve all move-away-edit
as mine-conflict and leave all the others" or "resolve all move-away-edit
as mine-conflict and all delete-edit as working and leave all the others".
The only other option being to break the move and not apply the update
to the move destination.
Does that make sense?
Note that I am referring to options offered by the CLI user interface,
not the API. The API might expose more low-level operations as has been
requested by GUI client developers in the past. But since we haven't
really advanced the conflict resolution API yet, I suppose we should
try to do the best we can do for 1.8 using the existing API.
> Another thing that needs thought is finite updates. The move-update
> code requires the move source to be single revision (and no subtree
> switches). This is fine most of the time, the move source can only be
> committed when it is equivalent to HEAD so mixed revisions are not that
> useful. The problem is that various things can make the move source
> temporarily mixed-rev: an interrupted revision or an explicit update of
> only part of the deleted tree. Command line users probably don't do
> finite updates very often but I think it is more common for GUI users to
> do so.
>
> When such an update happens a move-away-edit tree-conflict is raised but
> now it cannot be resolved as 'mine-conflict' to transfer the changes to
> the move destination as the move source is not suitable. At present the
> user's only option is 'working' which breaks the move into a copy and
> delete. What the user probably wants is to be able to fix the move
> source so that the 'mine-conflict' option is possible. That involves
> allowing the user to run update/switch on the root of the move while the
> move-away-edit tree-conflict is present. I think it would work but it
> is not currently supported.
So the resolver should perform a recursive update of the move source in
this case, again as part of of the "apply the update to the move" resolution
strategy, should it not?
Received on 2013-02-15 16:54:56 CET