On Wed, Jun 17, 2009 at 12:49:58PM +0200, Emmanuel Blot wrote:
> However, it seems that some "sticky" svn:merginfo properties keep
> being edited with no apparent reason when I merge unrelated changeset.
> I'd really like to know whether it's a known bug, an expected (but
> highly cumbersome) feature, or something I did understand the wrong
> way ;-)
This has been discussed a lot lately. Check the archives.
> # A new branch is forked from the trunk.
> svn cp ^/trunk ^/branches/newbranch
>
> # Some directories are svn copied from another branch to the new branch
> svn cp ^/branches/oldbranch/a ^/branches/newbranch/a
> # The above command creates expected svn:mergeinfo on
> "^/branches/newbranch/a" directory
When you do this, you have performed a subtree merge with a consequent
creation of subtree mergeinfo. As you say, this is expected.
> # Now, a fully, unrelated changeset is merged into the newbranch
> svn co ^/branches/newbranch/a
> cd a
> svn merge -c X ^/branches/devbranch
> # where devbranch changeset [X] contains a single change from another directory
> svn diff -c X ^/branches/devbranch
> b/file.c (revision X)
>
> # After the merge, the unrelated branches/newbranch/a directory sees
> its svn:mergeinfo property updated
Right, because something else has been merged and your subtree merge
point branches/newbranch/a needs to know about that merge so that
Subversion doesn't attempt to merge those changes again in the future.
> After several rounds of merge commands, there are dozens of such
> svn:mergeinfo alterations that get propagated from branch to branch,
> which make svn st and svn diff quite difficult to read, as most of the
> printed change entries are not related to actual developer changes.
> Then developers start to get confused, and make errors.
>
> Is there any way to get rid of this behaviour ?
If you are 100% confident that you don't need Subversion to keep track
of the mergeinfo on branches/newbranch/a, you can remove the
svn:mergeinfo property. But in this case, I think that mergeinfo is
doing exactly what it's supposed to: remember which revisions have
already been merged into which subtrees in your repo.
hth,
tyler
Received on 2009-06-17 17:46:47 CEST