On Tue, Feb 26, 2008 at 9:01 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "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.
OK. Hmm. Can you give me a case where (c) would be false? ie, how
could P possibly have incompatible mergeinfo?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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 09:46:15 CET