RE: mergeinfo not inherrited when I thought it should

> 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
Received on 2010-10-29 17:18:45 CEST