Just a quick update: I specified the range to merge from trunk manually and the merge completed without error. Looking at the mergeinfo property svn correctly extended the last revision range.
-----Original Message----- From: Jens Christian Restemeier [mailto:j...@playtonicgames.com] Sent: 04 July 2017 11:01 To: 'Bert Huijben' <b...@qqmail.nl>; 'Johan Corveleyn' <jcor...@gmail.com> Cc: 'Stefan Sperling' <s...@elego.de>; 'users@subversion.apache.org' <users@subversion.apache.org> Subject: RE: "Unable to parse reversed revision range" when merging from trunk to branch You are correct, it is a sparse workspace directory, so I assume any merge touching the excluded directories is marked as non-recursive. The merge is a plain merge from trunk, so the "changes" range starts at the same revision as the rangelist (15014) and goes up to the then-current revision on trunk (20515). There are no gaps in rangelist and the last range has the same inheritance, so all it should do is extend the last range to 20515. -----Original Message----- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 04 July 2017 10:41 To: 'Jens Christian Restemeier' <j...@playtonicgames.com>; '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 > -----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
