thanks for the quick answer. It's safe to assume that the published mergeinfo paths are the only merge information on those folders/files.
And of course - if I didn't include the external then the problem doesn't emerge.
Von: Bob Archer [mailto:Bob.Archer_at_amsi.com]
Gesendet: Donnerstag, 14. Januar 2010 16:00
An: Andreas Ländle; users_at_subversion.apache.org
Betreff: RE: Problem with merge tracking information in conjunction with file externals
> I discovered an imperfection of subversion 1.6.6 (at least in my eyes)
> last days when I was merging some files from our trunk into the stable
> All the merge tracking information of all files in one directory have been
> The detailed situation was the following.
> / (added svn:mergeinfo /trunk:r4)
> /directory1 (added svn:mergeinfo /trunk/directory1:r4*)
> /directory1/file1 (added svn:mergeinfo /trunk/directory1/file1:r4)
> Take into account that file1 represents a few dozen files in the
> 'directory1'-directory (all with the same 'r4'-mergeinfo).
> In my eyes the merge information for /directory1 and the files in it is
> Shouldn't 'Mergeinfo Elision' consolidate the merge-tracking information
> down to the "root"?
This really depends on what other merge info is there. I assume those are not the only mergeinfo paths on those folders/files.
> Is this behavior correct? Or have I found a bug or at least an
> imperfection in subversion?
It is possible. I have heard people say that superfluous merge info is created when using externals. Have you tried your script without it containing externals?
> I have attached a batch script (see below) that reproduces the issue - or
> at least it should illustrate what I was doing.
> How can I avoid the creation of this bunch of merge tracking information
> during the merge?
> Surely, I can revert the merge-information on directory1 before committing
> my merges (but that seems to be very inconvenient).
Yes, that should be ok, assuming there is no other mergeinfo on that folder/files.
Received on 2010-01-14 16:25:11 CET