[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: Wed, 4 Feb 2009 19:47:15 +0000

On Tue, Feb 03, 2009 at 07:17:34PM -0500, Mark Phippard wrote:
> On Tue, Feb 3, 2009 at 2:59 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
> > This issue has come up a few times on IRC, but I don't know if we've ever
> > discussed it here, so I'm opening this can of worms now: Should the bindings be
> > spun off into their own project(s)?
> I completely understand the sentiment, but I think it is too late to
> do this (in SVN's history not specifically this release) and could
> interject a lot of uncertainty into the future of the bindings.
> We'd basically be asking each of the bindings to come up with their
> own build systems that had to deal with all the different ways
> Subversion can be built or packaged. There'd be a lot of uncertainty
> about whether packagers would include these bindings. As an example,
> Linux distros have only recently started to really support JavaHL as a
> package. It used to be really hard to get. I have great fear that if
> it is spun off it will just get dropped or it will be impossible for
> something like Subclipse to predict what version will be available or
> what version of SVN it supports.

As Hyrum pointed out, there are several bindings in existence
that are being maintained out-of-tree already.
So this is a solved problem!

> There is a lot of stuff out there that is built up around these
> various bindings and this sort of change could wind up creating chaos.

If that was so, then anyone maintaining any kind of code against our
APIs outside of our tree would wind up in chaos as well.

I think the API stability we provide is all that's necessary to
successfully maintain the bindings. I'm not a bindings developer,
so I cannot speak from my own experience. But it looks like there
are enough examples out there that justify this point of view.

> Also, as you touched on, while the bindings can be a PITA it is also
> hard to know how many release problems they have prevented by the
> things they uncovered. Things are a little better now because of the
> buildbot you added. Perhaps this can ultimately help this get better
> by spotting failures sooner.

That is the only point that concerns me, too. However, nothing stops
anyone from running any kinds of tests involving bindings against
our trunk on a regular basis. It's just that it's already set up
in an in-tree fashion right now. But there is no technical reason
why this advantage the bindings offer would have to go away if
they were being maintained out-of-tree.

Received on 2009-02-04 20:47:41 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.