brian:
> All I ask is that decisions about the future aren't made until 1.0
> (at least) is out the door.
I think there is enough good stuff in a good state there, as-is, to
freeze and stabilize 1.0.
The "hot" application that svn is currently ideal for is back-ending a
wiki. The resulting system will be a new paradigm for writing web
apps: the wiki content structuring and access model, stored in a
transactional file system. The best of both worlds (wikis and 3-tier
apps).
I think you should freeze the client and factor it out. Treat the svn
"client side" interface as a low-level interface. Assume that
fancier, higher-level, nice-ui clients will want to treat the svn
client-side as a back-end and leave it at that. Among other good side
effects, this immediately ends all kinds of endless fidling with, for
example, when to and when to not prompt interactively for a password.
It also saves you from having to struggle with all those pesky "edge
cases" that the CVS model has never had to deal with.
You can pick an arbitrary amount of time in which to stabilize a
frozen svn. I suggested 45 days for no particular reason other than
it feel right intuitively. Within whatever period you choose, just
make the goal a best-effort bug-fixing cycle.
I can't imagine that it would take more than a few weeks, at most, for
a good perl hacker to make a nice svn-based Twiki. Perhaps someone
can get into the consulting business of writing little extensions that
take advantage of the transaction facilities.
With a 1.0 close on the horizon, we could start talking seriously
about distribution and higher-level tools for automating work-flow.
-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 09:42:33 2002