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.
They don't share history, so i'm not sure what you mean.
In fact, unless they very specifically asked for that range of revs to
be merged in, it wouldn't be remerged by default.
My understanding is that our default merge if you don't specify a
revision range will be <highest revnum in mergeinfo for that path>:HEAD.
This would still avoid remerging your feature set, unless it was at the
very tip.
I'm very wary of recording reverse ranges in the same property, because
they really have the exact opposite meaning of everything in there right
now.
IMHO, it would significantly complicate merge combining, and most of the
rangelist operations.
If we want to record reverse merges like this, we should have
svn:antimergeinfo or something :)
Or maybe even "svn:blockedmerges", which is exactly how svnmerge does it.
At least, that's my initial thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 18:59:38 2006