3

If you have a directory with an svn:external link it in (which we use extensively at work), then whenever you merge that directory between branches, every file in the directory gets a new svn:merge-info property.

I'm guessing it's because the external link is not being changed by the merge so svn is counting it it's own subtree (related to, but not the same problem as Why would svn merge of a branch with no changes causes untouched files to modify svn:mergeinfo property).

This results in the actual change being buried in all the merge info property changes, making the changeset both large and almost unreadable. (We have a branch with enough merge history and externals that merging a one line change can result in a 500Kb diff).

So far the only thing we can do is delete the merge properties from the subtrees with svn:external links before committing. This prevents using --reintegrate and means we can't track real subtree merges if they happen.

Does anyone have any better solutions?

Community
  • 1
  • 1
Malcolm
  • 1,239
  • 1
  • 14
  • 25

1 Answers1

3

svn:merge-info isn't meant to be read but I understand your problem.

One solution could be to upgrade to 1.7 (both server and client). There is some work done on merge-info in 1.7 that might help you.

It sounds like you already understand merge-info but here is some extra information anyway.

merge-info on a node (file or directory) is inherited from it parent (director) all the way through your working copy and then further up to the repository. svn tries to write merge-info only on nodes where it is needed ie where it differs from it's parent.

To prevent merge-info on nodes make sure to merge as close as possible to the repository root and if any other merges has occured before try to merge in those holes from a upper directory. That would cause no changes but fill in the gaps in the merge-info making Mergeinfo Elision more effective.

I've found that some versions of svn doesn't work as intended when doing merges. 1.6.6 (the one ubuntu 10.04 have) doesn't work very well when doing partial merges.

Andreas Wederbrand
  • 38,065
  • 11
  • 68
  • 78