On Fri, Feb 15, 2013 at 03:07:36PM +0100, Stefan Sperling wrote:
> 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?
I've made some steps in this direction today following our discussion
this morning (see r1449727 and some later commits from me today).
Has this concern been sufficiently addressed now, such that this is no
longer a blocking issue?
> > 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?
I don't think the resolver is finishing updates of partly updated move
sources yet. I intend to look into this next.
Received on 2013-02-25 19:29:35 CET