Svndumpfilter updating mergeinfo incorrectly?

[Doros Agathangelou]

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