You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark Eichin <ei...@gmail.com> on 2008/10/21 02:52:47 UTC
How would I diagnose "Mergeinfo for '...' maps to an empty revision range" ?
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_ <ei...@thok.org> <ei...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How would I diagnose "Mergeinfo for '...' maps to an empty revision range" ?
Posted by Mark Eichin <ei...@gmail.com>.
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 <ei...@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 <ei...@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_ <ei...@thok.org> <ei...@gmail.com>
>>
>
>
>
> --
> _Mark_ <ei...@thok.org> <ei...@gmail.com>
>
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How would I diagnose "Mergeinfo for '...' maps to an empty revision range" ?
Posted by Mark Eichin <ei...@gmail.com>.
Turns out that the only way to diagnose this is to singlestep the
client. And since it uses apr heavily, starting with
https://svn.apache.org/repos/asf/httpd/httpd/trunk/.gdbinit
and adding a couple more macros (below) is the only way to proceed...
define dump_merge_range_t_array
set $dmrta_a = (char **)((apr_array_header_t *)$arg0)->elts
set $dmrta_n = (int)((apr_array_header_t *)$arg0)->nelts
set $dmrta_i = 0
printf "%u elts in merge_range\n", $dmrta_n
while $dmrta_i < $dmrta_n
printf "[%u] ", $dmrta_i
p *(svn_merge_range_t*)$dmrta_a[$dmrta_i]
set $dmrta_i = $dmrta_i + 1
end
end
document dump_merge_range_t_array
Print all the merge_range_t array in a mergeinfo_t
end
define dump_mergeinfo_t
set $dmt_h = $arg0->array
set $dmt_n = $arg0->max
set $dmt_i = 0
printf "%u/%u counted in mergeinfo_t\n", $arg0->count, $dmt_n
while $dmt_i < $dmt_n
set $dmt_ent = $dmt_h[$dmt_i]
while $dmt_ent != (void*)0L
printf "%d -> %s\n", $dmt_i, $dmt_ent->key
# $dmt_ent->val is an apr_array_header_t...
dump_merge_range_t_array $dmt_ent->val
set $dmt_ent = $dmt_ent->next
end
set $dmt_i = $dmt_i + 1
end
end
document dump_mergeinfo_t
print contents of svn_mergeinfo_t
end
On Tue, Oct 21, 2008 at 5:28 PM, Mark Eichin <ei...@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 <ei...@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_ <ei...@thok.org> <ei...@gmail.com>
>>
>
>
>
> --
> _Mark_ <ei...@thok.org> <ei...@gmail.com>
>
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How would I diagnose "Mergeinfo for '...' maps to an empty revision range" ?
Posted by Mark Eichin <ei...@gmail.com>.
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 <ei...@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_ <ei...@thok.org> <ei...@gmail.com>
>
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org