Hi Geoff,
Thanks for the response - I think I've done something odd with a merge
in the past, which has resulted in junk merge info, probably on trunk,
which is now getting propagated each time. My main concern was there
was some subtle form of corruption going on, since that seems to not
be the case I think I'll just live with it.
Thanks
Jeremy
2009/6/19 Geoff Rowell <Geoff.Rowell_at_varolii.com>:
> 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=2363552
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-19 17:52:40 CEST