svn:mergeinfo is acting strange

[Chris <de...@yahoo.se>]

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

Re: svn:mergeinfo is acting strange

[Pete Harlan <pc...@gmail.com>]

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 <st...@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

Re: svn:mergeinfo is acting strange

[Stefan Hett <st...@egosoft.com>]

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

Re: svn:mergeinfo is acting strange

[Chris <de...@yahoo.se>]

Hi,

I tried the tool that Stefan Hett recommended and did get rid of a all mergeinfo from some of the most annoying files, so hopefully it improves the situation for future merges. Thanks for the hint.

/Chris