> 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 > branch. > All the merge tracking information of all files in one directory have been > changed. > 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 > redundant. > 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. BOb <script snipped>
