[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Svndumpfilter updating mergeinfo incorrectly?

From: Doros Agathangelou <ntzimeil_at_gmail.com>
Date: Tue, 24 Jan 2017 20:03:27 +0200

 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

Received on 2017-01-24 19:03:36 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.