> In a quick test, we have a project which has the following > structure: > > /trunk/project/subfolder/file > > Next, we create a branch from /trunk/project to > > /branches/project/branch1/ > > We edit file on trunk a first time, changing line1 and commit > > Inside branch1, we do a merge from trunk. This creates mergeinfo on > /branches/project/branch1 > > We edit file on trunk a second time, reverting line1, changing > line2 and commit > > Inside branch1/subfolder, we do a merge from trunk/subfolder. > > > This last step ignores the mergeinfo on /branches/project/branch1/ > and merges all revisions again since we made the branch. I thought > inherrited mergeinfo would be used here to see that a first part of > the revision range did not need to be merged again. However, this > does not happen.
Did you commit the first merge? BTW: To minimize the merge info propgation you really just always merge from /trunk/project into your branch. If you only want a specific revision you can specify it... but still you want to keep all the mergeinfo in /branches/project/branch1 if you can... or else merges will start changing all kinds of properties on all your child nodes. > The result is that we merge the combination of the 2 edits, which > is only changing line2. > However, we had already merged the change to line1, so the revert > on > line1 should have been merged too. > > See attachment for a reproduction scenario. > > Is this scenario supposed to be handled by SVN ? > We are in a corporate environment, using 1.5.1. Is the above > scenario known to be handled correctly in later versions? > Is it a known issue? There were many merge issues fixed after 1.5.1.. you should get to the latest 1.6... or at the very least the latest 1.5. BOb
