Hello all I believe I discovered a potential bug in how svndumpfilter updates the mergeinfo property.
I would like your feedback on whether this is indeed a bug or if I am misunderstanding something in a grand way. The problem is that in revision 10, the merginfo property of /trunk:4,6,9 is updated to /trunk:4,6,8-9 when a) we use the --drop-empty-revs --renumber-revs options b) drop revision 9 by delete the files added in revision 9. Looking at the svn code, my understanding is that this happens because a merge range of 9 is represented as a range of 8-9 internally. When the 9 is updated to 8 (after dropping revision 9) we end up with a range of 8-8 internally. Clearly this is meaningless so the code that prints the merge range adds one to the ending range. My theory is that the correct approach would be to drop the 9 from the mergeinfo thus getting /trunk:4,6 Is my above theory correct? I am attaching a mergetest.dump based on a small test repository I created to illustrate the problem. To command that drops revision 9 is shown below for your convenience. svndumpfilter exclude --drop-empty-revs --renumber-revs /trunk/file-e.txt /branches/trunkbranch/file-e.txt < mergetest.dump > problematic.dump I looked in Jira and I could not find a relevant bug hence this email. Looking forward to the views of the community. Thanks Doros
mergetest.dump
Description: Binary data
