Re: reintegrate and renames

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.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org