[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Alexander Kitaev <alex_at_tmate.org>
Date: 2005-02-28 18:35:51 CET

Hello Ben,

Thank you for the great suggestion, I'm proud of it!

In general I think that it will be a great step forward for javasvn when it
will become part of subversion project. Even more, I think it is necessary
for javasvn to become part of subversion project to evolve into high quality
library that is considered as standard and "official" by java community.

So, reformulating suggestions made in this thread I could see the following
goals that me and subversion team shares:

- javasvn have to be fully compatible with native subversion client, both on
WC operations and network protocol (DAV/SVN) levels.
- javasvn have to progess faster then now, to reduce compatibilty "gap"
between it and native svn versions.
- javasvn should be recognized by java community as an "official" way to
work with svn, when pure java solution is needed.
- javasvn code and features quality should be comparable with native svn
client one, not to compromise subversion project.

Putting javasvn into subversion project repository will help to achieve some
of the goals, for instance, as Ben noticed, more developers will be able to
take a look at it, and especially subversion core team ones who may
recognize possible incompatibilites and suggest fixes for those. Following
subversion development guidelines will also help to improve library quality.
However, just putting javasvn into subversion repository introduces number
of issues, that I do not have solutions for yet:

- javasvn follows its own versioning scheme and have its own "tags"
directory and propbably will eventually have "branches" one.
- 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.
- 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.

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). 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)? Moreover, I think "stable"
version should be only included when javasvn will conform all requirements,
pass all tests, etc.

What is your opinion on it?

Thanks,
Alexander Kitaev.

> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Friday, February 25, 2005 6:31 PM
> To: alex@tmate.org
> Cc: 'C. Michael Pilato'; dev@subversion.tigris.org; 'Thomas Singer'
> Subject: Re: JavaSVN (Re: Subversion Branding / "whole
> product" (Was: Re: SmartSVN - a new Subversion client))
>
>
> On Feb 25, 2005, at 10:15 AM, Alexander Kitaev wrote:
>
> > But, regarding python tests I would like to let you know that I'm
> > already using (again, taking advantage of core subversion
> team work)
> > these tests for JavaSVN. There is a small subset of commands
> > implemented already and so far all "basic", "commit", "update" and
> > "status" tests pass (except those related to locking,
> because JavaSVN
> > doesn't support it at the moment).
> > My
> > ultimate goal is to make all tests pass and I'm sure it will happen
> > eventually.
>
> That's great news! I'm glad you're working toward that goal.
>
> I wonder if you'd be interested in folding the JavaSVN code
> into the main Subversion codebase? It would be really nice
> to ship JavaSVN as part of Subversion itself, the same way we
> ship perl/python/ruby bindings. Not only would it make
> JavaSVN more "official", but it would have more "eyeballs"
> reviewing it and contributing to it. I imagine that this
> would both increase JavaSVN's quality and accelerate its development.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 28 18:36:03 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.