[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-02-21 08:12:30 CET

Justin Erenkrantz <justin@erenkrantz.com> writes:

> I have an issue with moving the development of the bindings out of
> dev@svn, but I definitely don't have an issue with the bindings being
> separately released though from the core. However, the bindings are
> *extremely* tied into the core - in a way that no other SVN
> applications would be.

How's that? The SWIG bindings, at least, use only the public header
files, and like against the Subversion libraries, just like any other
client would.

> In the long run, I think it'll be beneficial to have them joined
> together not artificially separated.

The only way I can advocate keeping the bindings joined with the main
Subversion product is if the community can agree that the bindings are
first-class citizens -- that we spend time catching the bindings up to
the completeness level of their C counterparts, create a regression
test framework, and thereafter treat bindings bugs just as seriously
as core library bugs.

> I think cvs2svn can easily be split off as there is a clear
> demarcation line, but I just don't see the same rationale for the
> bindings.

The line is definitely not as clear, mainly because cvs2svn in no way
links against Subversion at all -- it generates a dumpfile based on a
documented format, and that's that.

But for me the line you're looking for involves essential-ness. If we
as a community say that the bindings are an essential piece of
Subversion, then we must start treating them as such (and can keep
them in this project). Otherwise, get 'em out.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 21 08:13:07 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.