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.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2371107
Received on 2009-07-13 23:26:01 CEST