Hi have the following situation:
libA and libB are sources from outside of my organization but I have
some local changes from times to times, so I use the "vendor branches"
pattern to keep track of these changes while allowing to get the latest
public changes when it suits me.
When I want to get those changes, I put the new versions into
/vendor/libA/current as one or more revisions, and once they are
committed, I merge the changes into /trunk/libs/libA.
This adds the mergeinfo property to /trunk/libs/libA which is quite
right as it keeps track of the fact that I merged the changes from the
Now, for some reason, I create a development branch to create a new
feature. I create it as a copy of /trunk because I suspect my changes
will touch many files in various folders.
Then comes the time when I keep my development branch synchronized with
the trunk, so I do a merge of the changes from /trunk. Let's say the
changes only modify files inside /trunk/subproject1 because that's the
only place where trunk development as taken place lately.
After the merge, the files are modified in /trunk/subproject1 and
mergeinfo is updated (or added if it's the first time) to the /trunk
folder. This is quite logical as I merged in /trunk.
But the mergeinfo properties are also modified in /trunk/libA and
/trunk/libB, even if the merge itself did not change anything inside
I find this quite disturbing because only those folders that already
have mergeinfo properties are updated. The other ones which do not have
merge infos are not touched at all.
What is the point to store the "/trunk:XXX" value inside the merge infos
for /trunk/libA when there are no changes?
It seems to me that the svn client updates the mergeinfo property if
it's already there, but it only adds a new one at the root of the merge.
I find it unsettling because I then have modified folders outside of the
places where the merge has changed anything.
Is it an expected behaviour?
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 16:48:28 CET