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

Sticky svn:mergeinfo ?

From: Emmanuel Blot <manu.blot_at_gmail.com>
Date: Wed, 17 Jun 2009 12:49:58 +0200


I've been using SVN 1.5 (and fight against invalid svn:mergeinfo
properties for a while).
I'm now using SVN 1.6.2 (w/ a SVN 1.5.5 server).

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 ;-)

A common use case:

# 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

# 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
# as follow
svn diff
Property changes on: a
Modified: svn:mergeinfo
   Merged /branches/devbranch/a:r9097

# This leads to an unexpected status, as directory 'a' never get
updated with this merge command,
although it appears as "(propery)modified"

svn st
 M . # expected
M b/file.c # expected
 M a # unexpected

I don't see the point of updated 'a' svn:mergeinfo property here, as
  1. 'a' has not been modified, AND
  2. 'a' was not part of the merged changeset

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 ?

Thanks in advance,


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-17 12:55:55 CEST

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