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

Brian,

I was not talking about backward-compatibility, I was talking about defining
standards, e.g. "Subversion 1", "Subversion 1.1", "Subversion 2". Each
standard should have an assigned test-suite. If a Subversion client finishes
these test-suite successfully, one can label it "Subversion x.y-certificated".

--
Best regards,
Thomas Singer
Brian W. Fitzpatrick schrieb:
> 
> 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.
> 
> -Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org