[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.