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

Re: 1.9.0-alpha2 up for testing/signing

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 4 Apr 2014 16:02:11 +0400

On 2 April 2014 21:02, Ben Reser <ben_at_reser.org> wrote:
> On 4/2/14, 2:37 AM, Ivan Zhakov wrote:
>> I didn't vote for 1.9.0-alpha2 because I believe that current trunk
>> should not be released even with alpha label. So effectively my vote
>> was -0.5, but I decided didn't express my vote if will be 3+3 people
>> interesting in driving 1.9.0-alpha2. But reality shown that developers
>> are not interested so much in 1.9.0-alpha2.
> You're entitled to vote as you see fit. But I don't think the reality matches
> what you're saying. There are only a handful of people that ever vote for
> Windows releases.
> Specifically over the last year (probably longer but I got tired of looking)
> the following people have voted for a Windows release:
> Johan
> Bert
> Ivan
> Mark
> Paul
> Mark has said that his Windows setup has rotted. Paul hasn't said anything, so
> I can't make any assumptions about his motives. Johan and Bert voted +1.
> The lack of one vote hardly seems to indicate a disinterest from a plurality of
> developers. Obviously, you're not interested.
And here is list of people voted for Unix release over the last year:
Stefan Fuhrmann
Stefan Sperling
C. Michael Pilato

I had to vote for both Windows and Unix for 1.7.13 and 1.8.3, because
we cannot get Unix signatures within week for very critical security


>> Even more I believe that fsfs7 stuff and log addressing stuff should
>> be reverted from trunk and such significant fsfs format changes should
>> be implemented in fsx to give users a choice: use stable and proven
>> format or something really new and never tested.
> I don't recall seeing objections to FSFS7 being on trunk and thus slated for
> 1.9.0 before this email. Seems rather odd to wait till now to object to them.
First time I raised my concerns about fsfs7 at SVN Hackathon 2013 in
Berlin and decision
was to implement *all* format changes in separate FS backend (FSX).
FSX was implemented, but some of significant
changes was copy-pasted to FSFS. Increasing code duplication significantly btw.

I've raised my concerns again on mailing list:

I think we shouldn't change FSFS disk format at least in Subversion
1.9.0, before we get some feedback about FSX ideas from the wild.
Because we can fix almost any bug in future, but it's extremely costly
to deal with on disk format mistakes.

But log-addressing branch was pushed to trunk.

> Even supposing we decided to remove it. There's nothing stopping us from doing
> this if we release 1.9.0-alpha2. We flat out don't promise compatibility
> between alpha/beta or even release candidate versions (we have even explicitly
> broken support for formats that have been in our release candidates in the past).
> So I'm really not understanding the objection here. If you really think FSFS7
> should be removed I think you should start a thread about that.
My opinion on Subversion 1.9.0 is the following: release Subversion
1.9.0 ASAP without FSFS format change. We have many FSFS performance
improvements in trunk that doesn't require format change.

I think that cost of maintaining disk format backward compatibility
and code destabilization doesn't worth the real benefits that users
get from fsfs7 performance improvements. On the other side: if
log-addressing and related stuff are so cool and rock-solid, users
always can switch to FSX and fully benefit from this new stuff.

Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-04-04 14:03:06 CEST

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.