Re: reintegrate and renames

So we haven't bothered to do the complex solution outlined here.

I chatted with dlr a little today about this. I think the right
solution for 1.5 is to provide some sort of force option that allows
the user to ignore the "branch has inconsistent mergeinfo" issue.

Specifically, I'd like to change svn_client_merge_reintegrate from a
"calculate the right two URL/revs pairs and then merge immediately"
API into a "return two URL/rev pairs, which the client can then pass
to svn_client_merge3 if it wishes" API. (This will presumably be
helpful for other merge tools as well as the svn client.) We can make
part of the return value be a list of paths that have inconsistent
mergeinfo and let the user decide if they want to do the merge anyway.

Without this, I fear --reintegrate will be a joke; it's bad enough
that Subversion barely handles merging renamed files in the first
place, but to forbid reintegrating branches with that is barely
usable.

This should be a lot simpler than the other stuff we discussed in this thread.

--dave

On Wed, Feb 27, 2008 at 11:15 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "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"
> >> >> <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?
>
> Fascinating.
>
> 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
> work.
>
> So, can we skip (c) ??
>
>
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>

-- 
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