Hi, If you're using Subversion 1.8, you may find this thread relevant:
http://thread.gmane.org/gmane.comp.version-control.subversion.user/118260 It describes specific instances in which Subversion 1.8 (and later) add mergeinfo to nodes. The mergeinfo there may be safely removed. --Pete On Thu, Jun 25, 2015 at 8:01 AM, Stefan Hett <ste...@egosoft.com> wrote: > Hi Chris, > >> 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 > > > We are facing exactly the same issue. I just got through dealing with this > on our case using a tool written by the SVN developer Stefan Fuhrmann to get > rid of redundant/unnecessary mergeinfo entries. It can be downloaded from > the svn-mergeinfo-normalizer branch in the SVN repository. The tool is > located under tools/client-side/svn-mergeinfo-normalizer. The branch readme > provides some basic information about what the tool does and how it can be > utilized. > > In principle it provides the following functionality (all done on a WC): > - analyzing the mergeinfo and reporting whether certain nodes can be > combined (and if not, what presents it from being combined) > - normalize the mergeinfo (basically removing redundant mergeinfo entries on > nodes) > - combine-ranges to combine the recorded revisions to a shorter but > semantically equal representation > - clear-obsoletes to drop mergeinfos for branches which no-longer exist on > HEAD > > Since you asked: I guess in most cases the reason for recording additional > mergeinfos is because (for some other reason) you ended up with adding > mergeinfos on a subnode (for instance test/some/unrelated/thing.txt. > As per definition of mergeinfos once a node (like thing.txt in ur case) > contains mergeinfo, it needs to contain all the relevant mergeinfo in its > own node. This is due to performance reasons as far as I understand it, so > that if u want to determine which revisions got merged into a node, SVN only > has to check out this one mergeinfo entry, rather than going up the tree to > determine which things got merged into this one. > > The good question here is why does it even keep record for revisions the > node is not impacted by. I asked the same question in February already on > this list (see: inconsistency between mergeinfo records). As far as I > understand this is done atm to keep the application design simple. There are > cases where the additional mergeinfo is required on nodes (for instance when > adding a new file in a directory, the record needs to be kept on the > directory node so the mergeinfo is correct). Effectively things could be > improved (and as far as I've read here, it's on the radar for a later > version), but the current behavior is as it stands right now. > > If u're running under Windows and want to give the svn-mergeinfo-normalizer > tool a try, I could send u the executable I've compiled and am using myself > here. > > Regards, > Stefan
