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/).
This has nothing to do with client-server compatibility, mind you. It
simply means that folks have to dump and load their repositories. It's a
one-time bit of pain that brings all the things we'd want a new set of
repository backends to bring. Yes, there are always those folks using
ra-local access around which we have to dance and throw flower petals, but
those folks just have to suck it up and deal this one time.
Until then, we're stuck either trying to make sure that all our backends can
reasonable support the same features (lowest common denominator scenario),
or that we explicitly allow them to differ functionally and we somehow
communicate that gracefully all the way back to the client ("svn:error: The
repository backend chosen for you by your Subversion administrator and over
which you have no control doesn't support atomic moves. Have a nice day!").
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Feb 1 18:10:11 2007