cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Re: New CVS?
Date Sun, 19 Oct 2003 17:52:56 GMT
>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" <erik@bruchez.org> wrote in message
news:3F92CD4F.6020302@bruchez.org...
> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message