[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [merge-tracking]Fix for svn merge reversal bug

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-07-08 08:20:44 CEST

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

  • text/plain attachment: patch
  • application/pgp-signature attachment: stored
Received on Sat Jul 8 08:22:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.