You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2006/07/07 19:39:01 UTC
[PATCH] [merge-tracking]Fix for svn merge reversal bug
Hi All,
Find the attached patch to the defect explained in the log message.
With regards
Kamesh Jayachandran
[[[
Patch by: Kamesh Jayachandran <ka...@collab.net>
Assuming we have already merged 155-156 of /branches/b1 to wc.
'svn merge -r156:154 file:///path/to/repos/branches/b1' should remove
155-156
from the svn:mergeinfo property for '/branches/b1' after merging.
Without this
fix it does not.
The cause is rangelist api's are capable of handling forward paths not the
reverse paths.
* subversion/include/svn_mergeinfo.h
Made svn_range_swap_endpoints public, this function was originally a
static function in subversion/libsvn_subr/mergeinfo.c
* subversion/libsvn_subr/mergeinfo.c
(svn_range_swap_endpoints): Renamed function 'range_swap_endpoints'
'svn_range_swap_endpoints' as we want this function to be public.
(svn_rangelist_reverse): Calls 'svn_range_swap_endpoints.
* subversion/libsvn_client/diff.c
(update_wc_merge_info):
Reverse the merge ranges(a.k.a eraser) before passing to
svn_rangelist_remove().
]]]
Re: [PATCH] [merge-tracking]Fix for svn merge reversal bug
Posted by Daniel Rall <dl...@collab.net>.
On Sun, 09 Jul 2006, Kamesh Jayachandran wrote:
> Hi Dan,
>
> Your patch works fine and simple!.
Thanks Kamesh, committed as r20484.
- Dan
Re: [PATCH] [merge-tracking]Fix for svn merge reversal bug
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Dan,
Your patch works fine and simple!.
With regards
Kamesh Jayachandran
Daniel Rall wrote:
> On Sat, 08 Jul 2006, Kamesh Jayachandran wrote:
> ...
>
>> Assuming we have already merged 155-156 of /branches/b1 to wc.
>> 'svn merge -r156:154 file:///path/to/repos/branches/b1' should remove
>> 155-156
>> from the svn:mergeinfo property for '/branches/b1' after merging.
>> Without this
>> fix it does not.
>> The cause is rangelist api's are capable of handling forward paths not the
>> reverse paths.
>>
>> * subversion/include/svn_mergeinfo.h
>> Made svn_range_swap_endpoints public, this function was originally a
>> static function in subversion/libsvn_subr/mergeinfo.c
>>
>> * subversion/libsvn_subr/mergeinfo.c
>> (svn_range_swap_endpoints): Renamed function 'range_swap_endpoints'
>> 'svn_range_swap_endpoints' as we want this function to be public.
>> (svn_rangelist_reverse): Calls 'svn_range_swap_endpoints.
>>
>> * subversion/libsvn_client/diff.c
>> (update_wc_merge_info):
>> Reverse the merge ranges(a.k.a eraser) before passing to
>> svn_rangelist_remove().
>>
> ...
>
> Kamesh, thanks for detecting this problem. As we discussed on IRC, I
> think we actually need to reverse the order of the svn_merge_range_t's
> in the RANGES parameter -- in addition to the end points of each
> element -- for svn_rangelist_remove() to work correctly (as it expects
> sorted input).
>
> svn_rangelist_reverse() ought to do the trick here -- give the
> attached patch a try.
>
> - Dan
>
> ------------------------------------------------------------------------
>
> Index: subversion/libsvn_client/diff.c
> ===================================================================
> --- subversion/libsvn_client/diff.c (revision 20472)
> +++ subversion/libsvn_client/diff.c (working copy)
> @@ -1750,7 +1750,11 @@
> rangelist = apr_array_make(pool, 0, sizeof(svn_merge_range_t *));
>
> if (is_revert)
> - SVN_ERR(svn_rangelist_remove(&rangelist, ranges, rangelist, pool));
> + {
> + ranges = svn_rangelist_dup(ranges, pool);
> + SVN_ERR(svn_rangelist_reverse(ranges, pool));
> + SVN_ERR(svn_rangelist_remove(&rangelist, ranges, rangelist, pool));
> + }
> else
> SVN_ERR(svn_rangelist_merge(&rangelist, rangelist, ranges, pool));
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] [merge-tracking]Fix for svn merge reversal bug
Posted by Daniel Rall <dl...@collab.net>.
On Sat, 08 Jul 2006, Kamesh Jayachandran wrote:
...
> Assuming we have already merged 155-156 of /branches/b1 to wc.
> 'svn merge -r156:154 file:///path/to/repos/branches/b1' should remove
> 155-156
> from the svn:mergeinfo property for '/branches/b1' after merging.
> Without this
> fix it does not.
> The cause is rangelist api's are capable of handling forward paths not the
> reverse paths.
>
> * subversion/include/svn_mergeinfo.h
> Made svn_range_swap_endpoints public, this function was originally a
> static function in subversion/libsvn_subr/mergeinfo.c
>
> * subversion/libsvn_subr/mergeinfo.c
> (svn_range_swap_endpoints): Renamed function 'range_swap_endpoints'
> 'svn_range_swap_endpoints' as we want this function to be public.
> (svn_rangelist_reverse): Calls 'svn_range_swap_endpoints.
>
> * subversion/libsvn_client/diff.c
> (update_wc_merge_info):
> Reverse the merge ranges(a.k.a eraser) before passing to
> svn_rangelist_remove().
...
Kamesh, thanks for detecting this problem. As we discussed on IRC, I
think we actually need to reverse the order of the svn_merge_range_t's
in the RANGES parameter -- in addition to the end points of each
element -- for svn_rangelist_remove() to work correctly (as it expects
sorted input).
svn_rangelist_reverse() ought to do the trick here -- give the
attached patch a try.
- Dan