Hello Branko,
> BTW, what does javasvn do about file:// access?
It is not supported, but if someone would like to add support for "file://" access, plugging it in should not be complex - there is a plugable API for SVNRepository implementations (currently there is one for "svn" and "svn+ssh" and one for "http" and "https").
> Is there any particular reason that the APIs are currently
> different, or is this just an accident?
JavaSVN API provides more control over the WC (for instance, it is possible to provide different WC format at runtime, also it introduces "workspace" objects that allows caching of wc information at runtime). In general I think separate API for WC operations is not necessary, but so far it is there and used by SmartSVN and other clients. Also JavaSVN includes API that is similar to subversion "include/svn_ra.h" and allows to work with repository. JavaHL implementation uses this "internal" JavaSVN API.
I agree with you on other points you've made and finally I would like to say that I would like JavaSVN to be included into Subversion repository.
Regarding APIs and tests I have the following suggestion:
- Standard Java API is one currently provided by JavaHL.
- To reuse python WC layer tests java command line client should use JavaHL only (currently it is not the case). Java command line client probably should be separated from javasvn.
- JavaHL API is not easy to extend now, i.e. there are lot of "package local" classes and no way to plug-in implementation at runtime, this should be changed to allow easy implementation "switch" without replacing API jar, but only implementation one.
- AFAIK, currently there is no way to test "repository" layer of JavaSVN directly, so I think, JavaHL API should be extended to provide interface similar to "svn_ra.h" against which repository tests should be written. JavaSVN already includes such interface (called SVNRepository), so may be it make sense to move it into "common" API part.
- May be it makes sense to reorganize repository layout slightly by introducing "bindings/java" directory with "common", "javasvn" and "javahl" directories below it, first may contain java command line client and standard API, while other will contain javasvn and javahl implementations.
JavaSVN license is exact copy of Subversion license (see it at http://tmate.org/svn/license.html) and includes reference to Subversion license as well. The only difference is that JavaSVN is copyrighted by TMate Software, not by CollabNet. Is that possible to leave reference to TMate Software in the lciense or should it be completely removed?
So, I would like to ask person responsible for subversion repository, to grant me commit rights in the repository location where javasvn is supposed to be located. At first I would like to put it there "as-is", i.e. create "tags" and "trunk" directories below that location and import all the files from http://72.9.228.230/svn/jsvn/trunk/ into "trunk".
Am I understand correctly that I will become "full commiter" in javasvn area?
Thanks,
Alexander Kitaev.
> -----Original Message-----
> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Wednesday, March 02, 2005 7:44 AM
> To: alex@tmate.org
> Cc: 'Ben Collins-Sussman'; dev@subversion.tigris.org; 'Thomas
> Singer'; 'Marc Strapetz'
> Subject: Re: JavaSVN (Re: Subversion Branding / "whole
> product" (Was: Re: SmartSVN - a new Subversion client))
>
> Alexander Kitaev wrote:
>
> >- javasvn follows its own versioning scheme and have its own "tags"
> >directory and propbably will eventually have "branches" one.
> >
> >
> That should not be a problem. But I'd recommend that,
> whatever your versioning scheme is, it includes information
> about compatibility with a particular version of SVN, both in
> terms of protocol (server) compatibility and WC compatiblility.
>
> BTW, what does javasvn do about file:// access?
>
> >- javasvn doesn't use any code from the subversion
> repository (except
> >for tests and JavaHL interfaces, that are referenced with
> "svn:externals").
> >- above also means that javasvn is distributed separately from svn,
> >having its own versions line and these distributions doesn't include
> >any of subversion code (that is not needed for pure java
> development).
> >- javasvn has its own API and introduces "adapter" code that
> implements
> >JavaHL API over its own API, it is not clear whether both
> APIs should
> >be considered as "official" or JavaHL only.
> >
> >
> I think it would be an extremely good idea if JavaSVN and
> JavaHL had exactly he same API. This would allow the
> libraries to share the abstract interfaces, and only the
> implementations would be different (one in native bindings,
> the other in Java). If we're going forward with the
> whole-product idea, we should create a common Java API in the
> org.subversion package anyway (now that "we" (that is, Karl)
> own subversion.org). And we should also introduce a
> consistent API versioning scheme for Java (both flavours),
> similar to the rules we have for the rest of Subversion.
>
> Is there any particular reason that the APIs are currently
> different, or is this just an accident?
>
> >- right now javasvn API is not stable and its code doesn't conform
> >subversion code quality. Javasvn command line client is not
> completed
> >and not all python tests pass on it.
> >
> >
> That's not a problem.
>
> >What I would like to say (exuse me for my poor english), is that I
> >fully agree on including javasvn into subversion repository (to get
> >more attention to it, to speed up development and to make it more
> >"official"), but at the same time I would like it to keep some
> >attributes of the standalone project (i.e. versioning,
> distributions).
> >
> There's no reason why versioning and releases could not be different.
> Although in the long run, I'd expect the two "flavours" of
> SVN to converge.
>
> >As I read in this mailing list, I would like to treat
> javasvn more as a
> >part of subversion "product" or "family", rather than part of the
> >"project".
> >
> >May be it make sense to include only "stable" version of
> javasvn into
> >subversion repository, keeping "trunk" version in the different
> >repository (or in the different branch of subversion repository) and
> >provide javasvn releases from this "trunk" separately from
> the native
> >subversion (at least till javasvn reaches full 1.1 compatiblity)?
> >
> No, I think that would actually be a bad idea because it
> would reduce JavaSVN's visibility within the project, and
> you'd lose most of the benefits of being in the same
> repository in the first place. Since JavaSVN code depends on
> only a small part of what's currently in the repository, and
> there's no dependency in the other direction at all, it would
> be easy to just drop javasvn into the SVN trunk. Later on,
> I'd expect to see more and more common infrastructure being
> used (the API, Java tests, command-line tests, etc.), but
> that would happen gradually.
>
> > Moreover, I think "stable"
> >version should be only included when javasvn will conform all
> >requirements, pass all tests, etc.
> >
> >
> You mean, included in the repository, or included in a
> release? If the former, I don't think there's any reason to
> delay the move. The SVN trunk is for development, it's not a
> showcase for finished code, so it's perfectly natural to have
> work-in-progress in the repository. Another important reason
> for getting JavaSVN into the SVN repository sooner is that
> people are more likely to review your code, and you're more
> likely to get help from SVN developers, if the code is there.
> All of which will help to make JavaSVn "conform to all
> requirements" sooner.
>
> -- Brane
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 3 15:04:40 2005