> 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). IMHO, the Subversion
client/server protocol needs to become some kind of standard, e.g. like J2EE
standard. Everybody is free to implement it himself, but the standard
exactly defines, when a client is standard-conform, e.g. it defines the edge
cases.
I definitely wan't to avoid a derivation like with CVS. Every CVS server
behaves different for some edge cases, because there is no CVS standard at all.
--
Cheers,
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 26 10:31:59 2005