jcorvel_at_tigris.org wrote on Fri, Aug 26, 2011 at 04:38:07 -0700:
> ------- 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
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.
> 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).
> To unsubscribe from this discussion, e-mail: [issues-unsubscribe_at_subversion.tigris.org].
Received on 2011-08-26 14:03:26 CEST