subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Archer <>
Subject RE: mergeinfo not inherrited when I thought it should
Date Fri, 29 Oct 2010 15:18:05 GMT
> 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.


View raw message