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 <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-24 00:59:53 CEST