[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 first merge being revert does not record 'svn:mergeinfo'

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-07-10 14:32:49 CEST

Daniel Rall wrote:
> On Sun, 09 Jul 2006, Kamesh Jayachandran wrote:
> ...
>
>> If the first merge is revert, 'svn:mergeinfo' is not getting recorded.
>>
>> * subversion/libsvn_client/diff.c
>> (update_wc_merge_info):
>> If there is no 'svn:mergeinfo' recorded already and the merge is a revert
>> make use of the passed in 'ranges' for 'svn:mergeinfo' calculation.
>>
> ...
>
>> @@ -1751,9 +1751,14 @@
>>
>> if (is_revert)
>> {
>> - ranges = svn_rangelist_dup(ranges, pool);
>> - SVN_ERR(svn_rangelist_reverse(ranges, pool));
>> - SVN_ERR(svn_rangelist_remove(&rangelist, ranges, rangelist, pool));
>> + if (rangelist->nelts == 0)
>> + rangelist = ranges;
>> + else
>> + {
>> + 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));
>>
>
> This would record a reversed rangelist (e.g. "/trunk: 10-9, 7-5").
>
>
Yes, it is correct right?
> If a range list (e.g. "10-9, 7-5") for a merge source (e.g. "/trunk")
> is not recorded in a WC's merge info, it's implied that either there
> have been no merges from that source, or that merges haven't been
> recorded. Either way, I'm not really seeing why we should record the
> "reverted" range, as they either weren't already merged (likely a
> no-op?), or there's no history of them being merged (meaning we've no
> merge history to adjust).
>

Why not recording the reverse merges?
What about the following usecase?
Release_1 copied to Release_2
 From Releases_2's Wc someone trying to cut off some
featureset(associated with a changeset 'ry:x' in Release_1) of Release_1
by 'merge -rx:y Release_1' where 'x>y'.
If this revert is not recorded, later readding(forward merges) same
reverted subset for featureset of Release_1 to Release_2, would be
recorded, which would look bit odd, given the fact that both 'Release_1'
and 'Release_2' share the history.

P.S Incase we record reverse merges we need to be careful about -r5:4
case, this revert gets recorded as '5', then there would be a confusion
whether it is 4-5 or 5-4.

With regards
Kamesh Jayachandran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 14:31:49 2006

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