[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 13:15:28 -0500

"David Glasser" <glasser_at_davidglasser.net> writes:
>> >> When you encounter a file ("/branch/bar") whose mergeinfo disturbs the
>> >> desired uniformity, run:
>> >>
>> >> svn_repos_node_location_segments(repos, "/branch/bar"
>> >> 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.
> OK. Hmm. Can you give me a case where (c) would be false? ie, how
> could P possibly have incompatible mergeinfo?


I just erased a long mail in which I started down different scenarios,
only to realize that in each one, the reintegrate checks would only
declare non-uniformity if the merge source was, in fact, not uniform
w.r.t. the target. In other words, the existing algorithm should

So, can we skip (c) ??


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 19:16:22 CET

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.