cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bruchez <>
Subject Re: New CVS?
Date Sun, 19 Oct 2003 17:43:43 GMT

Please check your facts.

1) The *idea* of writing a CVS replacement may be old, but serious
    coding work on Subversion started only in 2000, incidently funded
    by Brian Behlendorf, the co-founder of Apache.

2) To write a Subversion client does not require a client written
    entirely in C. Check the svn-up project (,
    a Java interface for subversion. Granted, your client won't be 100%
    Pure Java, but a good project would be to write one, based on Java
    WebDAV and DeltaV (the protocols used by Subversion) clients. This
    BTW is probably more related to Apache Slide and the current work
    on JSR-147 and JSR-170.

I don't think you should dismiss Subversion that quickly without
digging into it more. It is a very serious project with a lot of
potential. Yes version 1.0 just aims at replacing CVS, but what
happens post-1.0 is still in the air.

Like you, I think a Java version would offer tremendous advantages
(think about the possibility to use a SQL backend for Subversion: how
easy this would be done in Java compared to C!), but this remains
entirely possible on the client side, and, why not, on the server
side, as you could write a Java server compatible with Subversion.


Robert Simmons wrote:

 > Yes, I have looked at that project. Its no youngster itself having
 > started in 95.Nine years is a long time in the computing world to
 > put a product into production. In fact it is usually lethal. Given
 > the pace of the industry, a product needs to hit in a usable version
 > in less than a year to be feasible.
 > In addition, subversion requires C to code clients to it. This
 > limits the scope of potential deployment strategies
 > significantly. In addition, C coding is resource intensive. Sure, it
 > might be marginally faster but it takes a C coder something near
 > three times as long as a Java developer to get a product to market.
 > I have other arguments with subversion as well. It doesn't do
 > multiple projects well, instead requiring that you create multiple
 > repositories, one for each project. It also fails to recognize the
 > dichotomy between a file version and a software version. Seeing
 > revision 5678 on a file that has never been changed is quite
 > .... strange.
 > Finally, by subversion's own admission they aren't trying to break
 > ground, but merely "replace" CVS.
 > Ultimately I think subversion presents a great source of research
 > for lessons learned, both good and bad, but does not represent the
 > future.
 > My vision is of an architecture that is extensible, powerful,
 > efficient and based upon commonly used standards. (Lets face it,
 > WebDAV is all but dead)
 > -- Robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message