Ben Collins-Sussman wrote:
> On 2/1/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> Ben Collins-Sussman wrote:
>> > On 1/30/07, Greg Stein <gstein@lyra.org> wrote:
>> >
>> >> And FWIW, I am very, very strongly against any notion of 2.0.
>> >> Personally, I see it as a failure in creativity. Shooting for 2.0 is a
>> >> shortcut. It's a way to avoid the difficult problems. It is a way to
>> >> shove development problems/maintenance at the bazillions of users that
>> >> Subversion has today. Consider: 1.x clients and 2.0 servers are not
>> >> compatible. 2.x clients and 1.x servers are not compatible. Each time
>> >> a user wants to check something out, they will need to know the
>> >> version of the server. Holy shit will that suck. Big time. Badly. One
>> >> month of extra development to ensure 1.x compatibility, or a bazillion
>> >> man-months of productivity loss due to a major version change. Eesh.
>> >> Doesn't seem like a fair tradeoff. Hey... to be fair, it's true that
>> >> I'm not personally spending that extra dev time, but I don't think
>> >> that means the point is any less valid. And if/where I get to assign
>> >> or volunteer time for svn dev? It'll be on 1.x. I think that the
>> >> *concept* of 2.0 is just giving up.
>> >
>> > I agree that if we define 2.0 to mean "break all compatibility,
>> > everywhere", then yes... it will be a huge PITA for users. But
>> > presumably, there's some big net gain that the users get in exchange
>> > for their forced-upgrade pain, no? Isn't that sort of the point.
>> >
>> > While I agree with your sentiment above, it also looks like an excuse
>> > to never, ever, ever release 2.0. Your argument above could apply to
>> > pretty much every radical feature or design-change that ever gets
>> > proposed in the future, couldn't it?
>> >
>> > So I'm curious, Greg -- in your mind, what *would* justify a 2.0?
>>
>> I've always kinda thought of "2.0" as the point where we finally say
>> two things:
>>
>> * we've had it with duct-taping features onto our existing repository
>> backends, and so we're ready to start clean with them, sans schema
>> compatibility concerns.
>>
>> * it's time to really drop our deprecated APIs and reset our function
>> version counters (s/svn_client_commit43/svn_client_commit/).
>
> My only problem with this definition of 2.0 is that like Greg's idea,
> it's defined in terms of "what's convenient for developers" -- i.e. we
> get sick of maintaining a bunch of deprecated APIs, we get sick of
> trying to add new features without toppling the house of cards, etc.
>
> What I'm trying to say: if 2.0 is going to be a huge pain for users to
> upgrade to ("you must upgrade all servers AND all clients! you must
> dump and reload!"), then we need to give them a really good motivation
> to go through all that. We have to offer them insanely amazing new
> features. Our press release for 2.0 cannot read, "Subversion 2.0:
> same as svn 1.7, but um... cleaner on the inside..."
Sorry, it's clear that I miscommunicated. I wasn't advocating that 2.0 is
*merely* code cleanup -- but that 2.0 gives us to the freedom to break
certain compatibility rules (fs schema, public API, but client-server compat
only if we have to) if we feel that doing so is justified by some
user-perceived gain of functionality or performance.
One (possibly bad) example: atomic renames. Our current BDB database
schema can only *barely* manage atomic renames, and the implementation is a
mess (not the fault of the coders; just the limitations of the schema). We
haven't even *tried* to get this working under FSFS yet. The problem isn't
insurmountable, of course. We can always throw more code at it, generate
more BDB tables or FSFS files, maintain indexes here and there and
everywhere necessary. But is it worth it? If tracking atomic renames means
that our backend performance starts to rapidly decline, or that the code is
so complex that its reliability and maintainability is in jeopardy (it's a
real problem, you know -- volunteers come and go, and bring/take knowledge
with them all the time), those are ultimately user-facing issues.
Don't be so short-sighted. The story might very well be, "Subversion 2.0:
same as svn 1.7, but cleaner on the inside, faster all 'round, built to
compatibly support a whole set of upcoming new features, ..."
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Feb 1 19:26:03 2007