Stefan Sperling <s...@elego.de> writes:
> On Fri, Feb 15, 2013 at 01:12:49PM +0000, Philip Martin wrote:
>>
>> 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?
Perhaps. Two issues: 1) one cannot then resolve without repository
access, 2) determining which switch/update (yes, switch can raise the
same problem) to perform to bring the source back to an acceptable state
might be tricky. Consider A as the root of a copy source:
local_relpath repos_path revision
A X/A 10
A/B Y/A/B 12
Should we switch to X/A@10, Y/A@12 or something else? We could simply
adopt an arbitrary rule such as: switch to the move root. Or perhaps we
could attempt to record the operation that caused the problem and derive
from that? An expert user might prefer a particular operation based on
an examination of the working copy state. Do we allow the user to
specify the operation?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
