[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] *Greatly* improve merge performance, but break(?) edge cases

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 10 Jul 2009 12:01:39 -0400

Thanks all for your time and thoughts.

Julian - re other solutions, I agree. In pursuing this particular
path I was trying to find a solution that could be backported to 1.6.
Other solutions to this and other general merge problems are
definitely being considered:
http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/solutions-whiteboard.txt.

Re everyone's concern about correctness: I do agree that sacrificing
correctness on the alter of performance is wrong. However, I'm not
sure the current behavior actually is correct. My wording here was
poorly chosen:

> The only problem is that this patch changes the behavior of merge when
> a subtree with explicit mergeinfo has different history, e.g. a
> subtree is deleted and replaced with a copy from a different branch or
> from the same branch but at a different point in it's history. In
> these cases revisions might be included or excluded for merging
> differently than if we ask the repos for the actual implicit mergeinfo
> (what we do today).

I didn't mean that with the patch might be inconsistent in its
behavior, I meant that it will differ from our current behavior (which
is inconsistent).

As I pointed out in issue #3443, currently implicit subtree mergeinfo
which differs from the root of the merge target's implicit mergeinfo
is *only* considered *if* the subtree has explicit mergeinfo. It is
quite possible for a subtree's implicit mergeinfo to differ but for
the subtree to not have explicit mergeinfo, in which case the implicit
mergeinfo difference is completely ignored. Put another way, the
current trunk/1.6 behavior is inconsistent in this situation. So no
matter how we define the correct behavior, at least some of the time,
merge presently does the wrong thing in this "edge" case.

My change would make every subtree's implicit mergeinfo a function of
the merge target's implicit mergeinfo. A subtree's implicit mergeinfo
would not potentially change, as it effectively does today, depending
on whether the subtree has explicit mergeinfo or not. (/me wonders if
anyone actually follows this)

So the patch brings consistency...

...but maybe it makes things consistently wrong. As I rethink this,
I'm hard pressed to say if this is better or worse than how things
work today (ignoring the performance gains).

TODAY - If a subtree has no explicit mergeinfo and differing implicit
mergeinfo, the difference is ignored. If a subtree has explicit
mergeinfo and differing implicit mergeinfo, the difference is
accounted for. This means that merging into a target with
semantically equivalent subtree mergeinfo can produce different
results.

MY PATCH - If a subtree has differing implicit mergeinfo this
difference is always ignored, regardless of whether the subtree has
explicit mergeinfo or not.

So the real question becomes: Should we consider differences in a
subtree's implicit mergeinfo when calculating what needs to be merged?

If the answer is yes, then my patch is wrong as it would take us from
sometimes wrong, to always wrong. If the answer is no, then it makes
things always right.

Beware the easy "yes" and keep in mind that a subtree may *easily*
have differing implicit mergeinfo but have no explicit mergeinfo.
That means every path under a merge target potentially has differing
implicit mergeinfo and we need to detect this*

Paul

* That said, the answer probably is "yes" and this whole avenue is a
dead end (ending at a cliff edge above a river of lava).

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369822
Received on 2009-07-10 18:02:09 CEST

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.