subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Christian Restemeier" <j...@playtonicgames.com>
Subject RE: "Unable to parse reversed revision range" when merging from trunk to branch
Date Tue, 04 Jul 2017 10:01:10 GMT
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:bert@qqmail.nl] 
Sent: 04 July 2017 10:41
To: 'Jens Christian Restemeier' <jens@playtonicgames.com>; 'Johan Corveleyn' <jcorvel@gmail.com>
Cc: 'Stefan Sperling' <stsp@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:jens@playtonicgames.com]
> Sent: maandag 3 juli 2017 16:31
> To: 'Johan Corveleyn' <jcorvel@gmail.com>
> Cc: 'Stefan Sperling' <stsp@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 




Mime
View raw message