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

Re: reintegrate and renames

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Wed, 27 Feb 2008 00:01:19 -0500

"David Glasser" <glasser_at_davidglasser.net> writes:
>> Possible solution:
>>
>> When you encounter a file ("/branch/bar") whose mergeinfo disturbs the
>> desired uniformity, run:
>>
>> svn_repos_node_location_segments(repos, "/branch/bar"
>> <HIGHER_REV_OF_MERGE__PROBABLY_HEAD>,
>> SVN_INVALID_REVNUM,
>> SVN_INVALID_REVNUM,
>> receiver_func, receiver_baton,
>> authz_read_func, authz_read_baton,
>> pool);
>>
>> The receiver_func should check the (svn_location_segment_t *)->path on
>> each invocation. If any of invocations have a path P that
>>
>> a) corresponds to a path T in the merge target, and
>> b) T matches the path given in the problematic mergeinfo, and
>> c) P has no mergeinfo /or/ has mergeinfo that would be compatible
>> with the uniform mergeinfo requirement
>>
>> then we can proceed with the reintegration. (Remember, P is really a
>> rev/path pair, since it comes from an 'svn_location_segment_t'.)
>
> OK. But is this likely to actually occur in the common case? I mean,
> great, so we trace back /branch/bar to /trunk/foo and then, um, I
> guess do yet another svn_ra_get_mergeinfo on that. But there's no
> mergeinfo *on* /trunk/foo *from* /trunk/foo, which is exactly the
> mergeinfo we're looking for. So does this actually work?

Sure, I think it does -- step (c) is compatible with what you say
above, no? We're not looking for mergeinfo per se, we're just
determining uniformity.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-27 06:01:31 CET

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