While gaps remain between JavaSVN and Subversion's C core, I see no
reason why you couldn't maintain your own versioning scheme and such
and still live in the Subversion repository. Subversion wouldn't
distribute JavaSVN in its tarballs and such -- you could release your
own.
When you have "caught up", though, I think it would make sense to
unify the versioning schemes (though perhaps still keep distribution
separate). And having your code in the Subversion repository should
help to expedite this "catching up".
Not to be a Fitzish wet blanket or anything, but you'd likely also
need to change your copyright and license to match what is used by the
rest of Subversion. I hope this isn't too great an obstacle though --
I *really* think the combination of these two efforts would be a
monumental step towards world domination. :-)
"Alexander Kitaev" <alex@tmate.org> writes:
> 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
---------------------------------------------------------------------
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:54:40 2005