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

How would I diagnose "Mergeinfo for '...' maps to an empty revision range" ?

From: Mark Eichin <eichin_at_gmail.com>
Date: Mon, 20 Oct 2008 22:52:47 -0400

Looking at code, the message only appears if parse_revlist is handed
an empty string, and that can only happen if a pathname and a literal
":" have been found.

prop_tests.py even has an explicit test for that case.

If I look at all 194 of the svn:mergeinfo properties in my entire
repository (a large one, converted from 1.4 a few thousand commits
ago) I find some that are completely zero length; the rest have
path:revlist (some revlists are single numbers, some ending in *, some
ranges... but nothing that's blank after the ":"...)

I get the message running "svn log -g" on a file which currently has
no svn:mergeinfo. (Earlier, I was also getting it when attempting to
merge a change into a branch; using --ignore-ancestry got the merge
itself to apply, then fixing the mergeinfo to match an identical
change on a different branch didn't help... and then removing it
didn't help either... if log -g looks at historical versions of
properties, which it seems like it must, is there anyway short of
svndumpfilter (on a 17G 86000 rev repository) to clean up said
versions, assuming we can identify which ones are actually causing the

Any suggestions beyond "adding printfs to libsvn_subr/mergeinfo.c" to
figure out what properties it's actually having trouble with? (strace
-e file does show what revisions it's looking at, which narrows down
the possibilities, but none of them have invalid-looking mergeinfo,
and most of them have none at all...)

_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-10-21 04:53:08 CEST

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.