Hi, we've been using SVN for a large in-house project for a number of years and the longer time goes by, the more strange the svn:mergeinfo properties behave. I don't know if the "issues" are completely expected, if our repository somehow has ended up in a state that is unwanted or if there's something bug somewhere.
What happens: Whenever someone merges a branch onto the trunk, there are approximately 100 files/directories that get added mergeinfo despite these files (or files under them) not being affected by the commit. That the root directory of the trunk should be modified makes perfect sense to me, but if my merge only affects src/foo/bar.txt, why does it then have to set mergeinfo on e.g. test/some/untelated/thing.txt? It seems to be the same set or files/dirs that always get tagged with additional information, so I suspect that some previous merge has made these specific files add all future mergeinfos into them, while other files that didn't get this strangeness stay unaffected. E.g. I have two source files in the same directory: File1 has 367 lines of mergeinfo (367 different branch merges, that is), file File2 has 0. And both these files are equally old, so it makes no sense that they should differ that way. Is this expected or has our repository become overzealous? If the latter: can I "fix" this situation by manually deleting the mergeinfo from files "further down in the tree"? And if I do that, how badly will upcoming branch merges be affected? This isn't a major issue, but there have been cases where we've had conflicts inside the mergeinfo in these "special files" which has been sort of difficult to resolve for some committers. It is also quite annoying that every time we do "svn update" after a merge, we get 100+ lines of updates even if just one file has been modified (especially annoying in tools like subclipse). TIA, Chris
