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