>From the page on tigris.org I saw that one guy started by founding a company to improve cvs. At any rate the duration of the project is irrelevant. I Spent some time last night studying the code. Its typical C. Bythat I mean monolithic- difficult to extend and difficult to maintain.
In addition there are amany concepts that I dont agree with in subversion. Some of which I enumerated in my reply. However, Im lookign for an extensible framework. Not a monolithic program. Furthermore I am lookign for 100% pure java and indepence in deployment options; MySql, oracle, etc ... -- Robert "Erik Bruchez" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Robert, > > 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]
