RE: Continually increasing merge data on irrelevant files

On Thu, June 18, 2009 10:49 AM, Jeremy Wilkins <jeremy_at_jdwilkins.co.uk>
wrote:
> Hi All,
>
> I've got a 1.5 repository with several feature branches, these get
> merged to trunk. That gets merged with a testing branch. That in turn
> gets merged into a deployment branch.
>
> What I'm finding is that certain files which aren't being modified are
> continually getting merge data added to them. Its not added when the
> feature branch goes to trunk but trunk -> testing and testing ->
> deploy both add this merge data each time. Its always the same set of
> files.
>
> The repository set of as a 1.4 repo, got upgraded to 1.5 during 1.5's
> RC phase and is now being used with the stock Ubuntu 9.04 build of
> Subversion 1.5.4
>
> I'm assuming that this is some bug caused by an error in the
> repository, in which case how do I correct this? Would a dump/restore
> fix it or should I be upgrading to Subversion 1.6?
>

Jeremy, here's what I've learned.

Subversion 1.5+ handles merges by updating the merge info for the merge
target as well as any children of the merge target that currently
contain merge info. That last clause is the key one. It means that the
merge results depend not only on the content changes, but also on the
merge info prior to the merge itself.

Every time you pick a new file or folder as a merge target, a new set of
merge information is added. Subsequent merges will then need to update
that item's merge info. This "viral" activity produces confusing reports
when listing the changes from a merge.

This situation is further complicated by the lack of selectivity when
updating merge info. When an item's merge info doesn't currently
reference the merge source, it's updated by adding a new merge source
line - even though it was never a merge target on that branch. Using the
common development pattern of developing on branches, periodic merges
back to trunk and creating release branches from trunk will produce
release branches with all the merge info from trunk. That often includes
merge info from development branches that have been deleted/retired.

Adding yet more merge information can be avoided by requiring that
everyone only choose the root of trunk, or a branch, as a merge target.
This also requires that complete revisions be merged. That requires
additional care when deciding which content changes to commit as a
single revision. Crystal balls being somewhat murky, that can prove to
be a problem.

If your merge policy is to only merge directly from trunk, you can
reduce the clutter by deleting any merge info from a branch right after
it is created. If your branch already exists, you can delete any
non-trunk merge information.

---
Geoff Rowell | SET Senior & SCC Administrator
Varolii Corporation | geoff.rowell_at_varolii.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2363522
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].