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