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

Re: Spinning off the bindings

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 3 Feb 2009 23:27:29 +0000

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.

Received on 2009-02-04 00:27:53 CET

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.