zack:
> What Subversion 1.0 will be is pretty much nailed down, at
> this point.
May I suggest a simplification? (See the enclosed.)
sussman:
> That's why it's so easy for me to state this opinion:
> switching our goal to "design a perfect system" is
> essentially equivalent to tossing all of Subversion out the
> window.
Nothing could be further from the truth. Please see the enclosed.
zack:
> 'arch' is not going to be a satisfactory solution for me or an awful
> lot of other people, until every last line of shell script goes away.
I should be embarassed for you :-)
But fine -- see the enclosed. It proposes your goal in a svn-specific
way.
! How SVN can reach 1.0 by 15-Nov-2002
* Summary
The goal of this plan is to plot the way to a 1.0
svn release that can: (a) be reached quickly; (b) is worthy
of being called `1.0'; (c) has a good chance of maximizing
adoption of svn, within six months of release.
To achieve the goal, we consider what SVN is already best
at, ponder what "hot" applications can make the best use
of that functionality, and then mercilessly slash the 1.0
agenda so that it beelines for that target.
The conclusions are: freeze; fix bugs.
Finally, we ponder what comes after 1.0.
* What SVN is Already Good At
The svn architecture optimizes for {simple selected files commit},
{individual file query}, {scalable operation}, and {web
integration}. The first three of those optimization characteristics
derive ultimately from the use of Berkeley DB as a back-end; the
fourth optimization characteristic derives simply from the coding
habits of the primary authors.
It doesn't matter, I claim, that there will be performance glitches
in the 1.0 release. Deployment of a _stable_ svn enables initial
experimentation by eventual customers -- so it's an important first
step. The important thing about performance is that the
_architecture_ is clearly optimizable and scalable without _too_
much work. It's a sane risk to make a small deployment of even a
sluggish svn given that its performance prospects are so good.
I don't know jack about collabnet's business model -- but perhaps
there's money in optimizing svn for specific workloads, post 1.0.
I'll also point to sendmail inc. and their approach to scalability
of a core system service, presented as a business.
** definitions
*** simple selected files commit
A commit of a small subset of the files in a tree, creating a
whole-tree revision.
"Simple" because, in the face of _some_ structural tree
rearrangements, this command can't be used or doesn't do what you
might expect.
*** individual file query
A repository query for the contents, history, or meta-data
pertaining to a particular versioned object.
*** scalable operation
The ability to handle a high transaction rate and large volume of
data and to scale in proportion to hw resources,
retaining the same optimization characteristics at all scales and
reasonable transaction loads.
*** web integration
The ability to serve optimized operations via web protocols.
* What SVN is Not Already Good At
Primarily, the client is not done. There seems to be ample
usability tweaks being discussed; there seems to be no shortage of
edge cases that aren't done and may prove to be quite difficult.
Administration is a little bit trickier than it ought to be. The
ease of making a tiny personal repository is slightly neglected.
These are exceedingly minor issues -- earlier adopters Will
Understand such minor defects, and adopt in order to support a
project who's 1.3 they want to rely on.
* What Applications Fit SVN's Strengths?
I can think of two "hot" application areas for which svn is well
suited. These are:
1) Revision Control for Wikis
Wikis are the future of blogging and many other internet
mediated communications technologies. Revision control,
pioneered by Twiki (I think) is commonly (and plausibly)
believed to be an important feature.
SVN repository performance characteristics are ideally
suited for Wikis, because Wiki interaction typically
consists of {simple selected files commit} and because we
can safely expect to see increasingly huge and active wikis
(hurray for {scalable operation}). {web integration} and
{individual file query} are central to what Wikis do. The
weaknesses of the svn client interface are immaterial to
svn's application to wikis, because they are surely good
enough as-is to be used as a back-end to wiki-apps.
2) Web-accessible revision libraries for large numbers of
large, active, and long-lived programming projects.
This is my personal bias, again, but I think we'll see an
increasing need for "alexandrian" libraries of free
software code. Like wikis, libraries will benefit from
svn's performance strengths, and not care about its cli
weaknesses.
While svn certainly needs improvement in
cheapness-and-ease-of-administration, that's a long term project
that should be combined with the project of realizing its potential
for scalability. As with sendmail, I think you can postpone all
that optimization work until after deploying a 1.0 aimed at mostly
professional admins -- then let market demand drive (and pay for)
the improvements.
* What to Do, Then?
SVN needs _no_ new features, nor any internal improvements for the
two applications named -- especially for the Wiki application.
Freeze, fix bugs, and call it 1.0.
* And Then What? What About Post 1.0?
** Abort the Client
Paul Lussier wrote:
> Does CVS really need replacing? It's hobbled along for so long that
> everyone using it is pretty comfortable with the way it works.
> Couldn't they survive until not only something better came along,
> but until the *best* something else came along?
I think that's right on the money.
Personally, I think we should build a workflow-based client.
Instead of refering to revision control ids, I should be able to
refer to tasks. For example, I should be able to say "I want to
prepare a bug fix for GCC" and, based only on that, get a project
tree (working directory) all set-up for me -- based on what the
current HEAD branch is, and on my relationship to the core
maintainers. When I say "commit" -- that might perform revision
control ops -- or it might prepare email to send.
A workflow based client would make us all more able to fluidly move
between projects, would be a lot easier to use, etc. Importantly,
it wouldn't require much of either the `arch' or `svn' interface --
our CLI's just don't matter that much, other than that they'd be
convenient for calling from a front-end program.
By contrast, I'm not convinced that CVS-like interfaces have _that_
much of a future. Some people like them -- but then it took a
generation for `ed' to fall into the background, too. The fact is,
loosely speaking, those file-at-a-time interfaces aren't a really
good match for whole-tree transactions, and they are an awefully
low-level way to manage your project trees.
So, I'm thinking, post 1.0, keep the CLI pretty much frozen.
** Build the Workflow Client
I think this is a project for both `arch' and `svn' both to work on.
It should consist of exchange formats (for data describing
workflow). That way there can be more than one client.
Something like: the GCC project publishes its maintainer policies as
a machine parsable document (a program in a "tiny language") and
client programs interpret that, translating it into revision control
and email operations.
I'm really unclear as to whether a local, per programmer, svn
repository or arch repository should back-end the workflow client in
order to "stage" a programmer's work -- but I'm pretty sure that one
or the other system should.
** Implement Distribution
This consists of:
a) abstracting from arch a number of exchange formats and
protocols
b) polishing those protocols
c) enabling a mapping between those protocols and a svn
repository -- this accomplishes zack's anti-shell-script\
goal.
For `arch', step (c) is:
c) fix the implementation for the polished protocols
** Start Spin-off Projects
Start a project to port a free software wiki on to svn.
Start projects for distributed testing, distributed issue tracking,
and distributed release engineering.
Start a project to collect cilent UI improvements from users.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 12 01:12:40 2002