On Mon, 2009-07-13 at 09:42 -0400, Mark Phippard 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.
>
> 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.
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.
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.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370928
Received on 2009-07-13 16:34:15 CEST