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.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370911
Received on 2009-07-13 15:43:12 CEST