For the reference of future searchers - this appears to be caused by
doing merges into partial checkouts that go down different paths
through your hierarchy. Haven't found a way to avoid it in release
1.5.x clients other than "don't do that kind of merge" though I've
posted a potential fix to the dev list.
On Tue, Oct 21, 2008 at 5:28 PM, Mark Eichin <eichin_at_gmail.com> wrote:
> 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>
>
--
_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-31 19:43:00 CET