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.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.
>
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_at_subversion.tigris.org].
> >
Received on 2011-08-26 15:01:00 CEST