I have a related case where there's no mergeinfo mucking going on:
* file created on trunk
* trunk copied to release branch
* release branch tagged at release time
* release tag copied to new dev branch
* change made to file on trunk (so, not in natural history)
* sparse checkout of the dev-branch dir with just that file
* merge --depth=infinity -c revision uri-to-containing-source-dir
which reports
svn: Mergeinfo for 'trunk-path-of-file' maps to an empty revision range
All of the copies predate updating the repository to 1.5 (and the file
itself has no mergeinfo.)
What other mergeinfo should I be looking at that could be leading to that error?
(This, and the previous example, are with "svn, version 1.5.1
(r32289)" with the sharding-permissions patch from 1.5.2
cherry-picked.)
On Mon, Oct 20, 2008 at 10:52 PM, Mark Eichin <eichin_at_gmail.com> wrote:
> 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
> problem?)
>
> 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>
>
--
_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 23:28:21 CEST