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

Re: Higher level languages as part of the core of SVN

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-10-20 18:25:38 CEST

On 10/20/06, Giovanni Bajo <rasky@develer.com> wrote:
> Garrett Rooney wrote:
>
> >> I don't get this. You're suggesting a non-mainstream under-supported
> >> second-class higher level language, just because the interpeter has
> >> a lower footprint than, say, Python? I don't remember anyone being
> >> concerned with Mercurial's memory occupation, or svk's.
> >
> > It's not memory footprint I'm worrying about, it's dependencies. It's
> > practical to just bundle Lua with the system, it's not so reasonable
> > for Perl or Python or Ruby.
>
> I understand your concerns.
>
> Deployment of Python application has gone a long way nowadays. We can ship
> self-contained executables for Windows (like Mercurial does), and typically
> you can just "require" (assume) an existing Python installation on the
> system. If you write your Python code with some stricter rule, it will work
> on any Python version in the last 4-5 years, which is enough not to create
> too many headaches. If we are speaking of SVN 2.0 here, it will be several
> years in the future anyway. For now, a Python command line client could live
> as external contribution until it's more mature, and that'd raise even more
> the chances that having Python installed is not a problem anymore.

You're missing the point. I don't care about writing the actual
command line client in something like python, I care about being able
to actually use something that is not C to write the logic inside the
svn libraries, at least the bits that don't do any heavy computational
work.

> > I'm not advocating a C API for calling into the actual command line
> > code, just for calling into the kind of thing we put into
> > libsvn_client, which is theoretically client agnostic.
>
> How many libsvn_client users are there, in the wild? Is there any idea about
> this number?

I'm not so concerned about people calling directly into libsvn_client,
but in allowing people to do so via language bindings, which are
considerably easier to construct if libsvn_client has a C API, as
opposed to the gymnastics that would be required if it was written in
python.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 20 18:25:54 2006

This is an archived mail posted to the Subversion Dev mailing list.