[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Wed, 04 Feb 2009 14:13:38 -0600

Mark Phippard wrote:
> On Wed, Feb 4, 2009 at 2:47 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> 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!
> Sorry, but bullshit. Just because people like Bert have put in effort
> to create bindings does not mean the problem is solved. Someone would
> have to recreate all this work for each of the bindings as they
> spinoff in their own projects. The stuff Bert did for SharpSVN is not
> going to help JavaHL etc. I am not saying the problem is in using our
> libraries from bindings, but creating and maintaining a working
> development environment.
> BTW, I bet that Bert has no desire to move SharpSVN into our project.
> He probably likes that he can add features and release on his own
> timeline. If I were building Java bindings today, I'd feel the same.
> But the bindings have been in the project from the beginning and now
> there are tools like Subclipse that exist and depend on them being
> consistently delivered along with the core libraries.

But the bindings are rarely delivered to the end user along with the core
libraries. Most *nix distributions put the bindings into separate packages to
reduce footprint and dependencies. We even distribute such packages for windows
on s.t.o. I posit that the same experience which exists today could be had even
if the bindings are in a different package.

>>> 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.
> Again, you misinterpret. Our API is fine and if I were building a new
> binding today I'd agree. I am saying there is an ecosystem out there
> of tools that use our API via the bindings. To suddenly make those
> separate could suddenly create chaos for the tools that expected them
> to be available.

I still wonder about this. Again, most people install the bindings via their
operating system package manager. Heck, if the bindings were distributed
separately, it might make it *easier* for tools to use them, since the bindings
have a much smaller footprint and could feasibly be shipped with the tool itself.

>>> 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.
> I think it comes down to timing. If I were maintaining a binding,
> odds are I would not be updating it with our trunk on a daily basis.
> At best, when we got to a RC phase I'd look into updating them and
> only then might I find the problems and be able to report them. We
> saw some of this with 1.5 where the problems with the API found
> downstream did not show up into right before the final release. The
> bindings MAYBE allow us to catch some of these problems sooner.

Only if they are being maintained. If they aren't being maintained, they cause
more problems due to bit rot than they are worth. And with all due respect to
Kou and Joe, we've seen this problem with the swig-ruby bindings time and again.
  (I suspect the other bindings would exhibit the same problems, were it not for
their lack of comprehensive test suites.)


Received on 2009-02-04 21:13:56 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.