Re: [Issue 2685] Move + Merge => lose modifications

On Fri, Aug 26, 2011 at 2:02 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> jcorvel_at_tigris.org wrote on Fri, Aug 26, 2011 at 04:38:07 -0700:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2685
>>
>> ------- Additional comments from jcorvel_at_tigris.org Fri Aug 26 04:38:06 -0700 2011 -------
>> Wouldn't it be better to repurpose this issue, rather than marking it fixed?
>>
>
> If you disagree with what I did to this issue, you're probably right
> (since I was doing a BFS and didn't study each issue in the deepest
> possible manner).
>
> In this instance I think we already have issues for that --- eg, compare
> Stefan's recent work on implementing moves/renames (which?) in wc-ng ---
> but if we don't, +1 to reopen.

No probs, you hadn't yet marked it fixed, so it's still open :-). You
merely commented that you *would* mark it fixed if no-one objected, so
that's what I did ;-).

I don't think this issue is made redundant by Stefan's work on support
for local moves (unless I'm missing something).

At least the fundamental question is still there: wouldn't it be
better if 'merge' would translate a move (or copy) into an equivalent
move (copy) operation on the merge target (rather than simply copying
the file from the merge source)? If that were the case, there would be
nothing to resolve in the scenario described by the reporter of this
issue.

OTOH, there might be other scenarios that get more difficult this way.
I haven't thought about it too much, so probably there is a catch
somewhere ... (or maybe it's just really difficult to implement / fit
in our architecture). I'm guessing there are some people on this list
who know way more about this than me :-) ...

-- 
Johan
>> Maybe there won't be data loss anymore, because a tree conflict will be flagged.
>> But I think it's still reasonable to expect svn to resolve this automatically.
>>
>> Or, on a more fundamental level: there is something to be said for having merge
>> "replay" a move on trunk into an equivalent move on the branch. If the source of
>> the move doesn't exist on the branch, a tree conflict could be flagged.
>>
>> A consequence of this would be that "svn log" on "/BRANCH/TOMOVE/test.txt"
>> follows a more logical path (i.e. it was copied from "/BRANCH/test.txt" (rather
>> than from "/TRUNK/TOMOVE/test.txt), which could have had several interesting
>> changes on the branch).
>>
>> I'm not sure if this would completely solve the "move + merge + modifications on
>> branch" issue (cf. Lieven's scenario in #desc9), but it certainly feels more
>> natural to me.
>>
>> So repurposing this issue into something like "Merge should apply moves/copies
>> as equivalent operations relative to the branch" or something similar makes
>> sense to me (or at least seriously investigate/analyze this approach).
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2830567
>>
>> To unsubscribe from this discussion, e-mail: [issues-unsubscribe_at_subversion.tigris.org].
>