On Fri, Mar 05, 2010 at 01:40:24PM -0500, Brad Heide wrote:
> For example, when I look at the history of revision 31673 in branch
> /modules/Core3/branches/3.12.x this is the only change in the log:
>
> /modules/Core3/branches/3.12.x/Res/Std/En_US/str/Global.string
>
> So revision 31673 had nothing to do with CliShell.cpp. How this revision
> got stamped on the mergeinfo of CliShell.cpp in the 3.15.x branch I have
> no idea.
It's perfectly valid to record mergeinfo on a path for a revision
which did not affect the path itself. Subversion cannot know if a
revision affected a particular path without looking at the revision,
which might mean contacting the repository for information.
Recording the revision as merged even though it did not affect the
path saves Subversion from having to ask itself "did the revision affect
this particular path and do I still need to merge it into this path?"
again in the future, i.e. avoid contacting the repository again to
get this information.
Consider how this logic applies to entire revision ranges being marked
as merged. E.g. mergeinfo like "/trunk:30-244" on your branch root
does *not* imply that any of the revisions 30 through 244 affected trunk.
It's possible that trunk was last modified in revision 29, you created
the branch in revision 30, then did a sync merge to trunk in revision 245
(which was a no-op except for mergeinfo changes) and then trunk is modified
again, for the first time since revision 29, in revision 246.
In this example, commits in the range 30-244 were either affecting
your own branch or other branches. But Subversion can record the entire
range as "merged", meaning "I've looked at all of this and any changes
made to /trunk from r30 to r244 (there were none) are included in this
branch -- I don't need to ask myself this question ever again".
> Figuring that the merginfo was all messed up on the affected files and
> folders, I removed the mergeinfo property from just the affected files and
> folders and committed the change. I then re-ran my test of re-merging
> something that was already merged and this time no differences showed up
> in the working folder (good!) So my problem appears to be fixed for now.
> How the bad mergeinfo got on these particular files I still don't know but
> I will keep an eye out to see if it happens again.
OK. Glad to hear you could fix the problem!
Stefan
Received on 2010-03-06 17:42:09 CET