Details

      Description

      If you move a folder in TRUNK, and merge this move in a BRANCH, svn will copy
      the files from TRUNK, and not move (relatively) the files from BRANCH.
      
      Which means you lose all modifications in BRANCH.
      I already lost many modifications because of this "feature" :\
      --
      Added : /TRUNK/TOMOVE/test.txt(Copy from path: /TRUNK/test.txt
      Deleted : /TRUNK/test.txt
      => Merge
      Added : /BRANCH/TOMOVE(Copy from path: /TRUNK/TOMOVE
      Deleted : /BRANCH/test.txt
      --
      

      Original issue reported by ozonegrif

        Issue Links

          Activity

          Hide
          dlr Daniel Rall added a comment -

          This is simply how Subversion works.
          
          When you merge a change from a revision range in trunk, the delta sent to the WC
          from the repository corresponds to data on trunk, not on your branch.
          

          Show
          dlr Daniel Rall added a comment - This is simply how Subversion works. When you merge a change from a revision range in trunk, the delta sent to the WC from the repository corresponds to data on trunk, not on your branch.
          Hide
          subversion-importer Subversion Importer added a comment -

          > When you merge a change from a revision range in trunk, the delta sent to the WC
          > from the repository corresponds to data on trunk, not on your branch.
          
          Except here, you don't merge a DELTA, you merge the WHOLE TRUNK file. You lose
          ALL the modifications in your branch.
          
          I think you didn't read my exemple carefully enough to see where the bug is.
          
          See "Copy from path: /*TRUNK*/test.txt"
          It should be "Copy from path: /*BRANCH*/test.txt"
          

          Original comment by ozonegrif

          Show
          subversion-importer Subversion Importer added a comment - > When you merge a change from a revision range in trunk, the delta sent to the WC > from the repository corresponds to data on trunk, not on your branch. Except here, you don't merge a DELTA, you merge the WHOLE TRUNK file. You lose ALL the modifications in your branch. I think you didn't read my exemple carefully enough to see where the bug is. See "Copy from path: /*TRUNK*/test.txt" It should be "Copy from path: /*BRANCH*/test.txt" Original comment by ozonegrif
          Hide
          subversion-importer Subversion Importer added a comment -

          More precisions from a friend, better than me in english :
          
          what seems to happen is that during the Merge operation, especially concerning a
          Move (of files or whatnot) there is a reference ("Copy from path" I am told)
          that is taken from the trunk but aplied to the branch. It seems that this
          problem originate in the use of absolute file path instead of relative file paths.
          
          the consequence being that a file from the branch is redirected to one in the
          trunk, replacing datas in the branch and therefore losing them prior to the file
          movement.
          

          Original comment by ozonegrif

          Show
          subversion-importer Subversion Importer added a comment - More precisions from a friend, better than me in english : what seems to happen is that during the Merge operation, especially concerning a Move (of files or whatnot) there is a reference ("Copy from path" I am told) that is taken from the trunk but aplied to the branch. It seems that this problem originate in the use of absolute file path instead of relative file paths. the consequence being that a file from the branch is redirected to one in the trunk, replacing datas in the branch and therefore losing them prior to the file movement. Original comment by ozonegrif
          Hide
          sussman Ben Collins-Sussman added a comment -

          This is precisely one of the scenarios that the "true renames" feature seeks to
          solve.  Because we define 'rename/move' as 'copy and delete', it leads to
          confusion in this arena.  If the original poster had simply renamed his file,
          then the rename would have translated correctly in a 'relative' way (rather than
          absolute) when doing the merge.
          
          So, I'm closing this issue because (a) this scenario is already really
          well-known, (2) we already have a branch in progress (and open issues) to solve
          this problem by implementing 'true renames'.
          
          

          Show
          sussman Ben Collins-Sussman added a comment - This is precisely one of the scenarios that the "true renames" feature seeks to solve. Because we define 'rename/move' as 'copy and delete', it leads to confusion in this arena. If the original poster had simply renamed his file, then the rename would have translated correctly in a 'relative' way (rather than absolute) when doing the merge. So, I'm closing this issue because (a) this scenario is already really well-known, (2) we already have a branch in progress (and open issues) to solve this problem by implementing 'true renames'.
          Hide
          subversion-importer Subversion Importer added a comment -

          Reopening (WONTFIX was always the wrong resolution anyway).
          
          Perhaps I don't understand this fully, but I don't believe that this is
          conditional on issue 898 (true renames) at all.
          
          As I understand it, we have a change on trunk that looks like:
          
           Delete /trunk/oldfile
           Add /trunk/newfile (copied-from /trunk/oldfile@rX)
          
          And when we merge that to /branch/esfoo, we get this change:
          
           Delete /branches/foo/oldfile
           Add /branches/foo/newfile (copied-from /trunk/oldfile@rX)
          
          i.e. the fact that we 'renamed' oldfile to newfile on trunk has been lost, and
          we've ended up replacing the file on the branch with one from trunk.
          
          I don't think that this is conditional on us getting a real rename operation. 
          When we do, the original change on trunk will look something like:
          
           Rename /trunk/oldfile to /trunk/newfile
          
          And we'll need to merge that as
          
           Rename /branches/foo/oldfile to /trunk/foo/oldfile
          
          However, we can get exactly the same behaviour by adjusting the copyfrom source
          in the A+D case - while that won't solve the general problem of merging a rename
          over a locally-modified file, that's _not_ what was being asked for here.
          

          Original comment by malcolm

          Show
          subversion-importer Subversion Importer added a comment - Reopening (WONTFIX was always the wrong resolution anyway). Perhaps I don't understand this fully, but I don't believe that this is conditional on issue 898 (true renames) at all. As I understand it, we have a change on trunk that looks like: Delete /trunk/oldfile Add /trunk/newfile (copied-from /trunk/oldfile@rX) And when we merge that to /branch/esfoo, we get this change: Delete /branches/foo/oldfile Add /branches/foo/newfile (copied-from /trunk/oldfile@rX) i.e. the fact that we 'renamed' oldfile to newfile on trunk has been lost, and we've ended up replacing the file on the branch with one from trunk. I don't think that this is conditional on us getting a real rename operation. When we do, the original change on trunk will look something like: Rename /trunk/oldfile to /trunk/newfile And we'll need to merge that as Rename /branches/foo/oldfile to /trunk/foo/oldfile However, we can get exactly the same behaviour by adjusting the copyfrom source in the A+D case - while that won't solve the general problem of merging a rename over a locally-modified file, that's _not_ what was being asked for here. Original comment by malcolm
          Hide
          subversion-importer Subversion Importer added a comment -

          B. Smith-Mannschott points out privately that I typoed a path in the last comment.  It should have read, of 
          course:
          
          "When we do, the original change on trunk will look something like:
           Rename /trunk/oldfile to /trunk/newfile
          
          And we'll need to merge that as
           Rename /branches/foo/oldfile to /branches/foo/newfile"
          

          Original comment by malcolm

          Show
          subversion-importer Subversion Importer added a comment - B. Smith-Mannschott points out privately that I typoed a path in the last comment. It should have read, of course: "When we do, the original change on trunk will look something like: Rename /trunk/oldfile to /trunk/newfile And we'll need to merge that as Rename /branches/foo/oldfile to /branches/foo/newfile" Original comment by malcolm
          Hide
          subversion-importer Subversion Importer added a comment -

          I would be very good to have this in 1.5. At least it would make svnmerge a lot
          more usable.
          Any agile team where refactoring i.e. renames/moves is the norm, this would be a
          true blessing (outside of addressing issue 898 completely maybe this may be my
          biggest issue in my mind).
          

          Original comment by jacmorel

          Show
          subversion-importer Subversion Importer added a comment - I would be very good to have this in 1.5. At least it would make svnmerge a lot more usable. Any agile team where refactoring i.e. renames/moves is the norm, this would be a true blessing (outside of addressing issue 898 completely maybe this may be my biggest issue in my mind). Original comment by jacmorel
          Hide
          lgo Lieven Govaerts added a comment -

          I think this issue is a bit more complex than what is solved with Malcolm's
          proposal.
          
          Take this scenario:
          1. Copy /trunk to /branches/foo
          2. On /branches/foo, change oldfile
          3. Rename /trunk/oldfile to /trunk/newfile
          4. On /trunk, change newfile <--- this is the tricky bit.
          
          Now, when merging the changes on /trunk to /branches/foo with current svn the
          changes from oldfile on the foo branch will be lost:
           Delete /branches/foo/oldfile
           Add /branches/foo/newfile (copied-from /trunk/oldfile@rX)
          
          Malcolm suggests to change the copyfrom source to get this result:
           Delete /branches/foo/oldfile
           Add /branches/foo/newfile (copied-from /branches/foo/oldfile@rX)
          
          With the proposal, while the modification in /branches/foo/oldfile (step 2) will
          still be there in /branches/foo/newfile, the change made to /trunk/newfile will
          be gone.
          What we need is this:
           Delete /branches/foo/oldfile
           Add /branches/foo/newfile (copied-from /branches/foo/oldfile@rX)
           Apply delta of /trunk/newfile from creation point to rX to /branches/foo/newfile
          
          I don't know that code well enough to say if this possible or not, but if
          someone knows how to do it without implementing true renames I'm willing to
          spend some of my precious free time to get it fixed.
          
          

          Show
          lgo Lieven Govaerts added a comment - I think this issue is a bit more complex than what is solved with Malcolm's proposal. Take this scenario: 1. Copy /trunk to /branches/foo 2. On /branches/foo, change oldfile 3. Rename /trunk/oldfile to /trunk/newfile 4. On /trunk, change newfile <--- this is the tricky bit. Now, when merging the changes on /trunk to /branches/foo with current svn the changes from oldfile on the foo branch will be lost: Delete /branches/foo/oldfile Add /branches/foo/newfile (copied-from /trunk/oldfile@rX) Malcolm suggests to change the copyfrom source to get this result: Delete /branches/foo/oldfile Add /branches/foo/newfile (copied-from /branches/foo/oldfile@rX) With the proposal, while the modification in /branches/foo/oldfile (step 2) will still be there in /branches/foo/newfile, the change made to /trunk/newfile will be gone. What we need is this: Delete /branches/foo/oldfile Add /branches/foo/newfile (copied-from /branches/foo/oldfile@rX) Apply delta of /trunk/newfile from creation point to rX to /branches/foo/newfile I don't know that code well enough to say if this possible or not, but if someone knows how to do it without implementing true renames I'm willing to spend some of my precious free time to get it fixed.
          Hide
          hwright Hyrum Wright added a comment -

          Moving to 1.6-consider as part of the post-1.5 issue sweep.
          

          Show
          hwright Hyrum Wright added a comment - Moving to 1.6-consider as part of the post-1.5 issue sweep.
          Hide
          hwright Hyrum Wright added a comment -

          Post-1.6 issue sweep.  Since 1.7 is already shaping up to be a large release,
          move to 1.8-consider.
          

          Show
          hwright Hyrum Wright added a comment - Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release, move to 1.8-consider.
          Hide
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment -

          If test.txt had modifications on the branch this would tree conflict, so no data
          loss.  I'll mark this FIXED unless someone objects.
          

          Show
          danielsh Daniel Shahaf (äñ§€¥£¢) added a comment - If test.txt had modifications on the branch this would tree conflict, so no data loss. I'll mark this FIXED unless someone objects.
          Hide
          jcorvel Johan Corveleyn added a comment -

          Wouldn't it be better to repurpose this issue, rather than marking it fixed?
          
          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).
          

          Show
          jcorvel Johan Corveleyn added a comment - Wouldn't it be better to repurpose this issue, rather than marking it fixed? 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).
          Hide
          subversion-importer Subversion Importer added a comment -

          Tree conflict, when I merge two branches together, is usually understood as :
          "I'm not good enough to do this automatically".
          
          A lots of tree conflicts happen because of a simple folder renaming, they
          definately should be solved automatically by SVN when merging. If not now
          (because it's not a simple matter), then in a future release.
          

          Original comment by ozonegrif

          Show
          subversion-importer Subversion Importer added a comment - Tree conflict, when I merge two branches together, is usually understood as : "I'm not good enough to do this automatically". A lots of tree conflicts happen because of a simple folder renaming, they definately should be solved automatically by SVN when merging. If not now (because it's not a simple matter), then in a future release. Original comment by ozonegrif
          Hide
          rhuijben Bert Huijben added a comment -

          Minor update: Since Subversion 1.8 you will be warned that you lost changes by 
          a tree conflict.
          

          Show
          rhuijben Bert Huijben added a comment - Minor update: Since Subversion 1.8 you will be warned that you lost changes by a tree conflict.
          Hide
          julianfoad Julian Foad added a comment -

          Bumping non-critical '1.9-consider' issues to 'unscheduled' now that 1.9 is near.
          

          Show
          julianfoad Julian Foad added a comment - Bumping non-critical '1.9-consider' issues to 'unscheduled' now that 1.9 is near.
          Hide
          stsp Stefan Sperling added a comment -

          I am declaring this issue as fixed by the new conflict resolver in 1.10.
          https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

          If the new resolver does not fix this problem for you, please send a detailed bug report to the users@ list, and we can open a new issue for any such specific problem after consideration.

          Show
          stsp Stefan Sperling added a comment - I am declaring this issue as fixed by the new conflict resolver in 1.10. https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver If the new resolver does not fix this problem for you, please send a detailed bug report to the users@ list, and we can open a new issue for any such specific problem after consideration.

            People

            • Assignee:
              Unassigned
              Reporter:
              subversion-importer Subversion Importer
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development