[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: JavaSVN (Re: Subversion Branding / "whole product" (Was: Re: SmartSVN - a new Subversion client))

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2005-02-25 23:16:58 CET

On Feb 25, 2005, at 9:42 AM, Ben Collins-Sussman wrote:

> So my real problem is that it's difficult for me to trust that JavaSVN
> is "deeply" compatible with the core C implementation.

Heh, this strikes me as funny. By a similar argument, your bank may
insist you must use the Microsoft Internet Explorer browser because
your bank tested it extensively and is sure it's "deeply" compatible
with their web-pages, but other browsers give them the willies.

When the IETF develops protocol standards, if I recall correctly, they
like two independent and interoperable implementations. It seems to me
really neat and a contribution to the overall project that JavaSVN has
been able to provide such an independent and interoperable
implementation of the client/server protocol.

The question that arises is that, is the core development group willing
to have such a "public" protocol (maybe with a certification test-suite
like Sun created for independent Java implementations -- or the
Subversion Python tests; are they up to that task?), or is the
client/server protocol to be considered "internal" to the svn C
libraries so that people that want to interoperate need to
reverse-engineer at their own risk of breakage (a la Microsoft Office

Given the attention to interface details by the Subversion developers
and the large test-suite, they may be a good place to embrace open-


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 25 23:24:45 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.