[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: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 13 Jul 2009 09:42:56 -0400

On Fri, Jul 10, 2009 at 12:01 PM, Paul Burba<ptburba_at_gmail.com> wrote:

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

It almost sounds like it would be better to apply your patch so that
merge is consistent. If some real world use cases start to show up
where the implicit mergeinfo of subtrees needs to be considered, then
it would make sense to tackle this for all merge scenarios. It sounds
like today we have the worse possible solution:

1) If the implicit mergeinfo really needs to be calculated, then in
many merges it isn't, so users are probably not consistently
experiencing or noticing problems, which means it will also be more
difficult for us to recognize that there is a problem. We do not know
if users are experiencing this problem.

2) If the implicit mergeinfo typically does not need to be calculated,
then users are experiencing a huge performance cost for no real
reason. We know for certain that users are experiencing this problem.

Given how bad we know that #2 is for people that experience it, the
idea of expanding this logic to cover all merge scenarios does not
seem like the right solution to put in place. So I'd be in favor of
applying your patch so that there is consistency and we can learn if
#1 is really an issue or not.

Mark Phippard
Received on 2009-07-13 15:43:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.