I'll respond to this, since others might be interested too.
Good.
We need that stabilization point in order to satisfy potential
users (and ourselves) that it's safe to replace CVS
installations with Subversion now.
What does "safe" mean in this context? People put huge libraries of
source under revision control, expecting the archive to last a very
long time (decades) and support a large, open-ended variety of uses.
How does the mere on-time "stability" of a particular system prove
that that system is "safe"? Does "stability" mean you are committing
to "upwards compatible changes only" after 1.0? If that's what it
means, how can a prospective customer decide if the functionality you're
stabilizing on is a wise selection?
All that resistence you put up to making changes to your 1.0 plans:
multiply that across a much-expanded user community, hang a lot more
of other people's investment on the significance of changes --- and
that's the degree of freedom _you're_ going to have post 1.0.
Let's suppose that, amazingly enough, sometime after 1.0, something
finally convinces you that it's wise to approach distributed revision
control by adopting arch-style naming conventions, logging mechanisms,
and changesets.
To implement those features in svn is likely to require lots of user
visible and client visible changes. It may change the way you expect
people to organize their source within a repository. In principle, it
can simplify your servers, protocols, and clients, though not
obviously in any strictly upward compatible way.
But it's post 1.0, now, and lots of users have started working with
assumptions about how they organize their projects and started writing
scripts based on those assumptions. 3rd party work on clients has
taken off too. Programmers have been trained. Books printed. Making
this kind of change _now_ is almost like asking those users to switch
to a whole new rev ctl system -- they'd have to migrate all their
data, scrap all their scripts, and train their programmers yet again.
Good luck!
I'm sorry if you think our current schedule is a mistake.
But, I'm equally confident you're wrong.
It's not quite symmetric. It's not just two bright guys staring each
other down saying "You're wrong", "No, _you're_ wrong".
I've been trying to explain what's missing int the 1.0 plans by
pointing out specific elements of the revision control problem that
are poorly addressed by the current direction of svn: technical
matters that I think you should consider when deciding your schedule.
Matters that the decisions you make now have impact on. Elements that
can, if anything, simplify svn in several ways.
I've been advocating for a renewed design phase to examine some pretty
central issues discovered while building the arch prototype, with the
output of this phase being some formal documents. While arch is far
from perfectly documented and explained, I think you've seen lots of
materials that make a good case for this design effort. (I'm not just
making a general claim, "Hey, slow down guys!" -- I've pointed out
lots of specific issues and some of their implications.)
But you (collectively) reply with generalisms like "a project must
stop trying to Be Everything To Everyone" and "Subversion will not be
a failed project". Those are great rules of thumbs, but we're not
really making symmetric statements of opinion here. Nobody, not even
me, is saying "fail" or "Be Everything to Everyone". I'm saying,
here's a list of revision control issues you ought to be thinking
about.
Besides, which is better:
(a) a 1.0 that says "We worked real had on this for a while
and got something that works and has some nice features.
Then we buckled down and stablized 1.0. Trust us, this is
a good design: don't you see those nice features? CVS
doesn't have those! We plan to catch-up and exceed
BitKeeper and other systems post 1.0 and doesn't this 1.0
prove we have a great `track record'?"
(b) a 1.0 that says "We have really thought about the design
space of revision control systems and made some informed
decisions based on that. Because we understand the design
space so well, we can characterize all the competing
systems out there quite precisely, comparing and
explaining their strengths and weaknesses in those terms.
We have clearly stated rationales for the decisions we
made in our system. Most importantly, we can prove all
this to you because we've written up a description of the
design space, and captured our decisions as (largely
separable) formal specifications. You don't have to trust
us, you can read these materials and, based on those,
understand for yourself why our design is so good. You
can be confident that this design is going to be stable
and winning 10, 15...20 years from now, and that it's
prospects are great for further, compatible enhancement
and extension during that period. Yeah, sure, we've got a
feature-list that blows CVS out of the water, but if
you're going to look deeper before making the critical
decision of how to manage your code, we've got the
materials to guide your inquiry."
we know when to stop adding scaffolding and start filling in
the building
A popular failure mode in public works is to undertake an ambitious
Grand Design, get a significant ways into the project, then discover
that the design is flawed or that the funding won't ever be
sufficient. The project "completes" by brute force, but the result
isn't pretty. A dam that was supposed to be the world's 5th largest
gets built, but the water can't ever fill it to more than 1/3 of the
intended capacity because the fault-lines were discovered late and the
fancy new concrete turns out to be more porous than expected. One end
of the set of new bridges across the Ohio river is started 15' off
target, work has to stop because the money runs out, and for 20 years
it's known as the "bridge to nowhere". In a dozen cities, the housing
crisis is addressed by architecting pretty (on paper) highrises for
low-income housing with all the architectural sketches showing smiling
happy people playing in the green, tree-filled courtyards -- but 20
years later Jane Jacobs figures out that these designs can't possibly
be comfortable to live in not least because, unlike traditional urban
environments, they aren't structured in such a way as to support a
healthy street life and local economy: and sure enough, the've become
dangerous, barren wastelands with depressed microeconomies: demolition
projects waiting for the funding.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 23:27:31 2002