[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: Giovanni Bajo <rasky_at_develer.com>
Date: 2006-10-20 18:20:49 CEST

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.

> 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?

Giovanni Bajo
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:21:07 2006

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.