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 (http://svnup.tigris.org/), 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.
-Erik
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
