[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: Mon, 13 Jul 2009 17:25:45 -0400

On Mon, Jul 13, 2009 at 9:42 AM, Mark Phippard<markphip_at_gmail.com> wrote:

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

Exactly! I guess I finally explained this issue correctly :-P

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

On Mon, Jul 13, 2009 at 10:33 AM, Julian Foad<julianfoad_at_btopenworld.com> wrote:

> Yes, this sounds better than keeping the present (inconsistent and slow)
> behaviour. (My earlier reply was based on misunderstood implications.)
> The only thing to beware of is if the real-world use cases that create
> differing implicit mergeinfo also happen to be the cases that create
> subtree mergeinfo. If that were so, then the (inconsistent) algorithm
> would have actually been producing consistently correct results in those
> cases, whereas changing it might produce wrong results. The cases that
> generate differing implicit mergeinfo are copies, I think. Copies used
> to create sub-tree mergeinfo, but not any more. That means... I don't
> know: that's as far as my brain goes today.

Copies haven't created mergeinfo since 1.5.5 (12/22/08), so it has
probably been long enough that if users were getting bit by differing
subtree implicit mergeinfo, that we probably would have started to
hear about it by now.

> I think therefore it's right to do this. If it should cause any problem,
> it will almost certainly be a problem that already existed in some
> corner cases (where there's differing implicit mergeinfo but no explicit
> mergeinfo), and we would want to know about such a problem anyway, and
> this will make it easier to find and diagnose.

I'll commit this change later tonight unless I hear any objections.


Received on 2009-07-13 23:26:01 CEST

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