CODEWITHSUNDEEP
svntortoisesvn
TownCube
TownCube

Reputation: 1310

Best practice use of svn:mergeinfo

We currently follow the practice of creating branches for all our new features/fixes before merging to the trunk. At the moment we are not committing the changes SVN attempts to make to the svn:mergeinfo property to avoid it becoming a giant list.

Is there any value in keeping the merge history in this property (even when it grows to a huge amount over the years, maybe we should purge it every x years)?

Perhaps only branches we think will require multiple merges should be added to the property?

Upvotes: 2

Views: 474

Answers (2)

mliebelt
mliebelt

Reputation: 15525

I see there 2 options for you:

  1. Don't use branching and merging for each and every issue and feature. Develop on the stable trunk, and ensure that the commits are done with reference to the issues and features. You want to trace what is done for what reason.
  2. Follow the policy of doing feature branches (and even issue branches, if they are complex ones), but then use the automatically generated mergeinfo to keep track. How do you know that a feature is reintegrated into the trunk, without any information (e.g. mergeinfo)?

I don't think that the sheer size of the merge tracking info will be a problem, the problem may be the many merges you have to handle (and keep track). And features that are reintegrated just add one line to the mergeino with the name of the branch, that is all that is kept.

Upvotes: 0

Lazy Badger
Lazy Badger

Reputation: 97282

  • Don't touch mergeinfo by hand
  • Branches for years without merges are bad manners and source of big headache

Upvotes: 1

Related Questions