[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: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-02-26 17:15:50 CET

On Feb 26, 2005, at 3:30 AM, Thomas Singer wrote:

>> It's not just about the protocol. If I checkout a working copy using
>> JavaSVN, can I then use the regular 'svn' C program against that
>> working copy with no problems? What about the opposite scenario?
> I wouldn't make this a requirement for JavaSVN. The important issue
> should be, that JavaSVN (AKA a client using this library) should be
> able to use a Subversion server and other people using the same server
> might use command line SVN. It is not /necessary/, that the working
> copy of the client using JavaSVN must be compatible to the one of the
> command line SVN client. It would be nice and currently is works that
> way, but it is not a requirement, because only the client using
> JavaSVN needs to be able to manage the working copy.
> BTW, +1 from me to make JavaSVN "officially" supported at tigris.org.
> This does not mean, that YOU need to develop it. It just means, that
> you should think twice about the consequences, when changing the
> client/server protocol (you already should do even without JavaSVN).

Subversion's public API follows the source and binary compatibility
policy as outlined at http://apr.apache.org/versioning.html, so any
changes to the protocol in any version of 1.x.x will be backwards
compatible with any other 1.(x-n).x release. We take this
compatibility *very* seriously.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 26 17:18:27 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.