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
Received on Wed Mar 2 09:32:48 2005