cmpilato:
> If it's any comfort, Subversion has been self-hosting (that
> is, the code to Subversion has been stored in Subversion
> itself) for well over a year now, and to date we've never
> suffered any lossage.
Um, no offense, but yes you have.
When svn.collabnet.net goes down for a day -- interpollated into a
commercial context -- that's a major lossage. What's payroll for a
day? It doesn't help when, days later, people are still saying "Hey,
you know, we oughta figure out why that happened."
And then there's design lossage. Read recent messages on the list
at http://www.red-bean.com/mailman/listinfo/changesets about edge-case
hell. For a commercial deployer, one relevant question is "are
processes we build on top of 1.0 going to be applicable to post 1.0
releases, when we expect to get features like `smart merging'."
I don't mean to speak gratuitous or unjustified FUD, and I _certainly_
don't mean to say "svn is dying". I only mean to say that there are
some non-trivial design and implementation issues that are pretty
significant uncertainties with uncertain future implications.
Revision control is so freekin foundational to so many things. A
"crash" or "big interface change" has much, much bigger implications
throughout organizations for revision control than it would have for,
say, the layout of menus in a window manager.
Don't gloss over stuff. Identify the problems worth solving, and use
that to justify investment (even in the form of early adopters) -- but
then don't understate the problems or their implications.
"Try not to screw the customer too badly." -- (a different) Sussman,
paraphrased.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 21 22:12:13 2003