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 <stefan_at_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
Received on 2015-06-26 00:14:26 CEST