> -----Original Message-----
> From: Jens Christian Restemeier [mailto:j...@playtonicgames.com]
> Sent: maandag 3 juli 2017 16:31
> To: 'Johan Corveleyn' <jcor...@gmail.com>
> Cc: 'Stefan Sperling' <s...@elego.de>; users@subversion.apache.org
> Subject: RE: "Unable to parse reversed revision range" when merging from
> trunk to branch
> 
> I narrowed it down to the code in subversion/libsvn_subr/mergeinfo.c line
> 892-898 in adjust_remaining_ranges. At that point next_range actually starts
> before modified_range, so my guess is svn_sort__array_insert has some
> unexpected behaviour.
> 
>    x892                   svn_merge_range_t *new_modified_range =
> x
>    x893                     apr_palloc(result_pool, 
> sizeof(*new_modified_range));
> x
>    x894                   new_modified_range->start = next_range->end;
> x
>    x895                   new_modified_range->end = modified_range->end;
> x
>    x896                   new_modified_range->inheritable = FALSE;
> x
>    x897                   modified_range->end = next_range->start;
> x
>    x898                   (*range_index)+=2;
> x
>   >x899                   svn_sort__array_insert(rangelist, 
> &new_modified_range,
> x
>                                           *range_index);
> x
>    x901                   /* Recurse with the new range. */
> x
>    x902                   adjust_remaining_ranges(rangelist, range_index,
> result_pool);                                                                 
>                                                     x
> 
> Intuitively it seems to be awfully complicated to expand a range to the end of
> a change, and then cut it down recursively with adjust_remaining_ranges.
> My first thought would be to step through "rangelist" and "changes" side by
> side in svn_rangelist_merge2, and to modify, insert or skip a range in either
> list until you're at the end. Though obviously I have no idea about all the 
> edge
> cases the current code most likely fixes...
> 
> So how should I proceed from here? Should I open a bug with my findings
> and the test case?

I see you already opened an issue.

To me it looks like the issue is related to mixing recursive and non-recursive 
mergeinfo inside the same range... (The ranges with and without a '*' in the 
string). I see that your example case in the issue has quite a bit of overlap 
with both these kinds of ranges.

It looks like your case triggers a very interesting edge case.

        Bert 


Reply via email to