Daniel Berlin wrote:
> Kamesh Jayachandran wrote:
>> 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.
After talking with dlr and madan, we are pretty much all on the same page:
Reverse merges should probably be recorded somewhere.
Blocking revisions from future merges (which seems to be your usecase)
is a completely different beast entirely.
My *personal* feelings are:
reverse merges should go in svn:reversemergeinfo or something
blocking revisions should go in svn:blockedmergeinfo.
Neither blocking nor reverse merges should be mixed with svn:mergeinfo
as it stands now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 19:23:04 2006