On Tue, Mar 17, 2009 at 04:47:02PM +0100, Olivier Sannier wrote:
> 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
> vendor branch.
> 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
> those folders.
> 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.
I believe that all of this is expected and correct. You only need
mergeinfo at the root of your merges because of implicit mergeinfo --
the mergeinfo at the top of the tree should be used for nodes in the
tree if those nodes do not have their own mergeinfo already set.
You may wish to review some of the concepts behind mergeinfo here:
And then if you still have questions, there's a lot more detail here:
Received on 2009-03-17 17:52:29 CET