> subversion project is trivial. I was simply stating that C++
> and Java being close relatives in syntax makes it
> relatively easy to move between one language and the next.
As noted by others, the resemblence between C and Java is not as close as
between C++ and Java. Since Subversion is apparently written in C, that's
not such a big advantage, if it's one at all.
Furthermore, translating between one language and another is easy for one
who is fluent in both; not so much so for one who is not fluent in one or
the other.
> Subversion work across all of them is far more trivial than
> porting that same code using C. I don't think this
> argument is disputed by anyone.
Except when the work of porting in C is already done, as it is in
Subversion.
> development team. What I was trying to imply is that in the
> field of networking, XML and DBs there are awsome
> mature open-source Java libraries out there that would do
> this for you and ease your development. Stuff like
> Hibernate simply does not exist under C/C++ (as far as I
> know), there are many other such examples.
<snip>
> my knowledge). The major benefit of using Hibernate
> in Java instead of coding this in C is that once coded *once*
> against Hibernate, your code will fit on top of *any*
> database. Hibernate abstracts away any DB-specific
For Subversion, those only come in to play if they are needed, and if C
libraries don't already exist for that purpose. For instance, of what use
is a generic database back-end to a version control program like SVN? I see
no benefit from being able to use SQL Server, Sybase, MySQL or any other
general purpose DBMS for SVN. It already includes, in platform portable
form, distributed in the program itself, two separate database
implementations that serve the purpose of versioning quite well, one of
which was designed for the purpose of versioning alone, if I understand it
correctly. What would the ability to use something else (not purpose-built
for versioning) *add* to Subversion's capabilities? Why would that make it
more attractive?
>
> My point is: there is a lot of value added in porting
> Subversion to Java.
I don't see any. It's already cross-platform. It certainly would not be
any *faster* in Java, at least not from what I've seen. It would require a
Java run-time that doesn't always play well with the host OS.
> Yes it would require work, but there are also advantages there.
> Please consider them with an open mind and feel free to discuss
> them with me on this mailing list.
You've given a number of good reasons why such a project might be *started*
in Java, but none that are compelling from the standpoint of "porting" to
Java. I see little to no advantage to the end user, and none that would
make the perfectly-competent-in-C developers to want to make such a port.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 27 00:39:25 2004