Hi Paul and others. It says in http://subversion.tigris.org/issues/show_bug.cgi?id=3020#desc19 "Reflect dropped/renumbered revisions in svn:mergeinfo data during svnadmin load":
> 5) Prevent svnadmin load from loading mergeinfo with r0 or r1 as a merge > source > revision. Both are meaningless as regards mergeinfo and the former causes a > parsing error. > http://svn.apache.org/viewvc?view=revision&revision=941408 > http://svn.apache.org/viewvc?view=revision&revision=941438 I think that's wrong. r1 is not invalid, merely unusual, as a merge source. For example, this works, when $REPO is a new empty repo: $ svn co -q $REPO wc; cd wc $ svn ps newprop v .; svn mkdir newdir; echo hello > newfile; svn add newfile property 'newprop' set on '.' A newdir A newfile $ svn ci -q -m "" $ svn copy $REPO@0 ^/branch -m ""; svn up -q Committed revision 2. $ svn merge -c1 ^/ branch/ --- Merging r1 into 'branch': A branch/newdir A branch/newfile U branch --- Recording mergeinfo for merge of r1 into 'branch': U branch I want to revert those two commits (modulo part of the big comment change in the test in the first commit). Note that the r941438 commit made 'svnadmin load' remove all references to r1 from mergeinfo. This has been in place since v1.7.0. I think it isn't important in the typical recommended scenarios for using Subversion, but we shouldn't be making such assumptions. I am looking at this code because I want to filter out any reference to r0 when loading, since that definitely is meaningless, for issue #4476 "Mergeinfo containing r0 makes svnsync and svnadmin dump fail". The r941438 commit doesn't appear to accomplish that, despite its log message. - Julian -- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>
