On Tue, Feb 03, 2009 at 01:59:30PM -0600, Hyrum K. Wright wrote:
> There are already other projects which maintain bindings for languages we do and
> don't include, such as SharpSvn, SVNCPP, PySVN and others[2]. Should we follow
> their lead and graduate our existing swig and JavaHL bindings into separate
> projects?
I like this idea for the reasons you already stated, and because...
- The bindings sometimes break the build for me, to the point
where I have set up my build environment so that I have to
explicitly call a different Makefile target to build them.
Binding issues are too distracting when working on Subversion core.
I don't know enough about the bindings to fix such issues,
and I don't want to know.
- As the subversion package maintainer for OpenBSD, I have already
inherited from my successor a "multi-package" setup where each
set of bindings goes into a different package, to reduce the amount
of dependencies the main subversion package pulls in.
A few dependencies would be shed off the Subversion core distribution.
- I have recently taken a look at 'svn-load', a very promising candidate
to replace svn_load_dirs (svn_load_dirs lacks a proper licence and
cannot be redistributed by package maintainers). I wanted to import
svn-load into our contrib/ directory. It uses the pySVN bindings,
however, so it would not be usable in our tree out of the box.
So my initial reaction was to put this item on my TODO list:
Port svn-load to swig python bindings and add to contrib/,
update svnbook accordingly, remove svn_load_dirs.pl
If pySVN had the same official status as the swig bindings,
I would not even have spent a thought on porting the script.
Complete waste of time.
Rather, we should encourage more proliferation of binding implementations,
and break down the divide between "official" bindings in our tree and
bindings maintained elsewhere.
- I guess that since our release APIs are stable, the bindings should
not have more difficulty keeping up in-tree than out-of-tree, once the
initial overhead of switching to out-of-tree mode is overcome.
I don't know if people use the bindings against our trunk code at all,
I've never heard of such use (certainly not in production).
> If we did, here are a few questions:
> * Where would we spin off the bindings to?
I'd say wherever the current bindings maintainers want them to go.
> * How much work would be involved in doing this?
Ripping out tons of cruft from the buildsystem (yay!).
Removing bindings-related material from the documentation.
Removing the bindings code and tests from our tree.
> * Should/can it be done for 1.6?
Not sure, I'd wait for opinions of current bindings maintainers
before making such a decision.
One option:
We could decide that for 1.6, we ship the bindings in whatever
state they're in, deprecating them. In 1.7, they won't be
shipped with Subversion core anymore.
Stefan
Received on 2009-02-04 00:27:53 CET