[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mergeinfo being copied during merges: confusing at least, maybe wrong

From: Greg Troxel <gdt_at_ir.bbn.com>
Date: Mon, 02 Mar 2009 18:44:50 -0500

I am the Chief CM Crank for a project with about 20 people working on it
in two teams. We have had a mostly good experience with merge tracking,
with a few issues. I'm writing to describe what happened and discuss
the issues.

Our repository has 20 or so top-level modules, as in

  http://foo.example.com/svn/${MODULE}/{trunk,tags,branches}
 
for MODULE in {module1, module2, module3, etc.}. (It is structured this
way because some modules are 3rd-party source and imported, some are
local, and there are different ACLs for different modules.)

We created a branch for one team, and they had done a lot of work on it.
About 8 of 20 modules are branched. We have had semi-frequent merges of
trunk to the branch, via doing for each module while on the branch:

  svn merge http://foo.example.com/svn/${MODULE}/trunk

Between merges, I noticed what I considered to be bad svn:mergeinfo on
the trunk in module foo, which was basically

  foo/trunk:500-800

This mergeinfo was present from merging trunk to a prior branch and then
merging the branch back. So I committed a revision that cleaned this
up, removing the self-referential mergeinfo.

The branch was rooted at say 700, and had mergeinfo of

  foo/trunk:700-900

Then when trunk was at 1000, I merged again and ended up (on the branch)
with

  foo/trunk:801-1000

as the branch mergeinfo.

I am pretty sure what happened is that the merge to the branch did two things:

  add mergeinfo for foo/trunk for the new revisions being merged
  (normal, correct)

  merge the removal of foo/trunk:500-800 from mergeinfo as a property
  change to the target mergeinfo. This seems wrong.

The basic issue seems to be that mergeinfo is special from any other
mergeable property change, sort of. mergeinfo for the source path or
the destination path should be ignored, and other mergeinfo changes
applied (so A->B, B->C record's A's changes as made on C). But, I think
mergeinfo changes of the source path on the source are treated as data
to be merged. As a fix, I think (but I'm not quite sure) mergeinfo for
either the source or destination branches on the source path should be
completly ignored during merges.

Separately, but related I think, I did a record-only merge of the
branch->trunk revision to the branch, so that we could continue to use
the branch (thanks Mark for explaining so clearly this in your blog
post). I got the revision N of the branch->trunk merge I wanted added
as

  foo/trunk:N

but I also got

  foo/branches/mybranch:A-B

where A-B are the revisions of mybranch that I had just merged to trunk,
creating self-referential mergeinfo. This seems wrong.

What seems to be happening here is that --record-only is limiting action
to changes to mergeinfo, instead of limiting to the addition of
mergeinfo from the merge - it should not apply source property changes
in this case.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1258798

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

  • application/pgp-signature attachment: stored
Received on 2009-03-03 00:51:59 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.