On Oct 20, 2006, at 17:20, Giovanni Bajo wrote:
>
> 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.
In support of what you are saying.
My pysvn Extension is written in C++. It lives between the C API of svn
and the C API of Python (hidden by my PyCXX library).
The main example for pysvn is a python clone of the svn command line.
I have most of the commands and most of the options. Its 1497 lines
of python.
The svn C version is 28765 lines include libsvn_subr.
The pysvn WorkBench GUI is delivered as a binary application on
Windows, Mac OS X and Unix.
>> 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?
Each of the GUIs that are built on top of use the libsvn_client API.
Some via
language bindings.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 23:28:20 2006