subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: "Unable to parse reversed revision range" when merging from trunk to branch
Date Tue, 04 Jul 2017 09:40:35 GMT

> -----Original Message-----
> From: Jens Christian Restemeier []
> Sent: maandag 3 juli 2017 16:31
> To: 'Johan Corveleyn' <>
> Cc: 'Stefan Sperling' <>;
> 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);                                                                       
> 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.


View raw message