> > 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.
>
> My question is, why the merge info is edited for branches, that are
> actually not modified?
I think all the spurious mergedata property issues were resolved it 1.5.5 and up. You are running 1.5.4 server, which may have something to do with this, not sure.
However, it seems like you are saying that merge data is being modified on a branch that is not the working copy that you are merging to? I can't see how that can happen.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2376671
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-29 19:45:49 CEST