Re: reintegrate and renames

On Sat, Apr 5, 2008 at 8:33 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Fri, Apr 4, 2008 at 11:01 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> > 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.
>
> Are you just being hard on this because it was your idea? I am not
> sure it is as bad as you say. It is possible that when you, Karl and
> Dan designed this you had bigger plans for this option, but I thought
> it was always about giving the user some syntactic sugar. Basically,
> make using 2-URL merge easier with some checks to make it safe. If
> those checks do not pass, the user still has a "force" option
> available, namely they can run the 2-URL merge themselves. Of course
> another option they have is to remove the extra mergeinfo if they do
> not want it.

Well, the big hole here is that svn doesn't actually tell the user
what the URLs would be to run it themselves. Separating the APIs
would help here.

> I am not against relaxing the checks or providing more "sugar" if we
> are comfortable doing so, but I am not certain it cannot wait until
> after RC1 or even after GA.
>
> First, while we know of situations that will easily create this
> problem situation, we still do not know what the real world
> ramifications are. How prevalent will the problem be, and just as
> importantly, whether in those situations the "right" answer would be
> to relax the checking. It is possible the solution can come from
> elsewhere as well. For example, maybe in the scenarios where this
> comes up, and relaxed checking is the solution, we could have solved
> the problem when it was created. In other words, maybe there was more
> checking we could have done before we created the extra mergeinfo that
> caused the problem.
>
> Second, while we could do some 2-URL merges now and test this out, I
> wonder if there will be some new eliding scenarios that will come out
> of this. In other words, you have this extra mergeinfo, you do not
> care about it, you tell reintegrate to --force itself to run. Now it
> runs the merge. Do we know what the 2-URL merge does with the
> mergeinfo? I think we know it does the "right" merge, but will we be
> creating new expectations about what it does with that extra
> mergeinfo?
>
> I guess I am just proposing we wait until we know the entirety of the
> problem in real situations. The user has a relatively easy "out" in
> the current code (namely they can run the 2-URL merge and get the
> identical results. We can optimize this for 1.6 if we see the need,
> or we can even do it before RC2 if after you look at the problem
> deeper you become more convinced it is the right thing to do now.

Well, take a peek at one of the XFailing reintegrate tests and see how
unreasonable it is...

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