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

[Johan Corveleyn <jc...@gmail.com>]

On Fri, Aug 26, 2011 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> jcorvel@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@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@subversion.tigris.org].
>

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

[Stefan Sperling <st...@elego.de>]

On Fri, Aug 26, 2011 at 04:00:15PM +0300, Daniel Shahaf wrote:
> I tested with rc1, and now with trunk, and in both cases a tree conflict
> is reported on the node that was modified on branch and
> modified+moved-away on trunk.
> 
> >From Stefan's commit messages I expected the issue to be fixed on trunk.
> (Namely, I expected trunk to merge the text mods into the moved target;
> though, admittedly, the mods in my testing would have text-conflicted.)

It only works for uncommitted local moves so far, i.e. moves reported
by 'svn status'. We need copy-to on the server to handle comitted moves.

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

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Fri, Aug 26, 2011 at 14:32:31 +0200:
> On Fri, Aug 26, 2011 at 2:02 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > jcorvel@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@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.
> 

I tested with rc1, and now with trunk, and in both cases a tree conflict
is reported on the node that was modified on branch and
modified+moved-away on trunk.

>From Stefan's commit messages I expected the issue to be fixed on trunk.
(Namely, I expected trunk to merge the text mods into the moved target;
though, admittedly, the mods in my testing would have text-conflicted.)

> 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@subversion.tigris.org].
> >