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

Re: Moving bindings into a separate project.

From: Ben Reser <ben_at_reser.org>
Date: 2004-02-20 20:40:21 CET

On Fri, Feb 20, 2004 at 01:59:32PM -0500, Garrett Rooney wrote:
> +1 on moving them 'somewhere', but i'm curious exactly how this should
> be handled. Several of the bindings depend on the same files (swig
> stuff), but could easily be released separatly. Would we really want a
> single subversion-bindings-1.0.x.tar.gz, or would it make more sense to
> have subversion-perl-1.0.x.tar.gz, subversion-python-1.0.x.tag.gz,
> subversion-java-1.0.x.tar.gz, etc. If that does make more sense, how do
> we handle the files that are shared between various bindings?

I think we'd have a subversion-swig-bindings-1.0.x.tar.gz package.
Other then that there's the javahl bindigs and com bindings.
Only the former seems to be maintained. The java swig bindings don't
seem to be maintained either. I think we should delete the bindings
that aren't being maintained and put a place holder like the ruby
bindings. If someone wants to resurrect them they can always cp the old
versions and start working on them again.

So really that means we're down to perl, python and javahl bindings. We
could probably easily release those as separate tarballs. We could have
a directory in our repo for the shared files and use svn:externals to
pull it in..

I don't know there are several ways to handle this. We just need to put
our heads together and figure out what makes the most sense.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 20:40:25 2004

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.