On Fri, Aug 7, 2009 at 10:17 AM, Paul Burba<ptburba_at_gmail.com> wrote:
> On Fri, Aug 7, 2009 at 9:53 AM, Greg Stein<gstein_at_gmail.com> wrote:
>> Hmm. I seem to recall asking about this branch, and the reply was
>> along the lines of "we're doing some investigation and running
>> experiments" or somesuch. IOW, no need to review the changes on the
>> And now... it is going to be merged. That's a pretty dramatic departure.
> Hi Greg,
> I don't recall what I said exactly, but as I said at the start of this
> thread my primary reasons for having it on a branch were:
> 1) I suspected the basic change the branch implements, not recording
> mergeinfo on subtrees unaffected by the merge, would cause a serious
> performance regression in certain use cases. I wanted to be sure that
> if such a regression existed and that it could be addressed. There
> was such a regression and it has been fixed on the branch.
> 2) The behavior change would cause a number of merge tests to fail,
> and I didn't want to go through the tedious work of fixing them until
> I was sure I could address #1.
> IMO it seemed like a branch was the way to go. All my* concerns have
> been addressed, it passes the test suite (more accurately it fails
> where trunk fails), and I think it is ready for trunk.
> * Obviously if others have concerns I want to hear them!
>> Has there been anybody reviewing the changes going into this branch?
> I don't believe anyone has been monitoring the branch on an ongoing
> basis no. That is why I posted this message a few days back and
> haven't been in any hurry to merge it back.
No other objections were raised so I merged the branch back to trunk in r38693.
Received on 2009-08-12 07:24:09 CEST