[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Time to branch 1.9

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 7 Nov 2014 08:46:22 -0800

> On Nov 7, 2014, at 8:30 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>
> On 07.11.2014 16:02, Mark Phippard wrote:
>>> On Nov 7, 2014, at 6:46 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>>>
>>>> On 07.11.2014 14:07, Ivan Zhakov wrote:
>>>> Actually, I have used my veto on the log addressing feature two months
>>>> ago [1].
>>> How many times do how many people have to explain that saying "-1"
>>> without substantiating that with technical reasons is not a valid veto?
>>>
>>> -- Brane
>> I think it is fair to ask whether it makes sense to introduce a fairly risky feature that adds marginal benefits into a mature and stable area of the code.
>
> Performance test results seem to imply that the benefits are far from
> marginal.

The bias I bring to the table here is that my view of a "typical" SVN deployment is an Apache SSL server that is serving at least dozens of repositories though often it is hundreds. With fairly random access across those repositories.

This might not be typical but in all the customers we have and market research we do it is.

From my reading of the info that has been posted I should not expect to see any benefits at all from this new code. We'll likely just force our repositories to stick with the 1.6 format and life will go on.

I just do not see why we do not just focus on FSX and making it a compelling choice. From a risk management point of view I do not think we have made any changes in the new formats that are worth deploying ... though I very much like the idea of directory deltification. The fact that we made it a configuration option scares me enough to not use or recommend it.

Mark
Received on 2014-11-07 17:48:28 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.