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.
I would make this a requirement. Otherwise subversion will become unusable.
I'm working in a bigger Java/Oracle project where we use differnet IDE's
with subversion plugins and we use the command line, TortoiseSVN and eSVN.
All the tools are used for the same WC or subtrees of it (projects and
subprojects). Because every Subversion client or integration has its
strengths and weaknesses we need almost all of them.
checkout: TortoiseSVN or eSVN
update and commit for Java parts: Eclipse with Subclipse* (or IntelliJ*
when they have the plugin ready)
update and commit for Oracle (and Java) parts: TortoiseSVN or eSVN or
scripts (command line)
branching: TortoiseSVN
refactoring (renaming, moving): Eclipse with Subclipse (or IntelliJ when
they have the plugin ready) - the plugins are essential
difficult stuff: command line
There is no and will be no perfect client which matches all requirements.
That's why, they must stay compatible also for WC.
Ingo.
*Subclipse and IntelliJ may use JavaSVN
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 1 22:01:03 2005