On 4/9/07, David James <james@cs.toronto.edu> wrote:
> What doesn't ctypes do?
> -- It doesn't generate high-level bindings for Subversion. Like SWIG,
> it only generates low-level bindings.
> -- It doesn't modify the C API in any way. It simply generates API
> functions in Python which work exactly the same as their C equivalents
> and have exactly the same interface.
>
> Note that, currently, the API for our low-level SWIG/Python bindings
> is noticeably different from our C API. See
> http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/python/README
> for details. When we switch to ctypes, these differences in the
> low-level bindings will go away, unless we choose to implement them
> again in ctypes.
It seems to me that it would be best to maintain the current bindings
implemented in ctypes for those who are used to the current bindings.
Since people do use the current binding (despite it's shortcomings) it
would be nice to remain as much backwards compatibility as possible.
From what I've seen on ctypes, it should allow the use of the same
binding with fewer bugs, I don't see any reason not to maintain that.
>
> So far, I've only implemented one change to the Subversion C API in csvn:
> - All functions returning an error through a svn_error_t
> automatically raise a SubversionException() instead.
>
> I don't think we should implement any other changes to the low-level
> Subversion C API in csvn. Any code which automatically changes the C
> API is likely to introduce bugs unless we are very careful. I would
> prefer to keep the low-level API simple (and largely identical to our
> Subversion C API), so that we can avoid introducing bugs. For more
> details on the rationale behind this, see
> http://svn.haxx.se/dev/archive-2007-04/0389.shtml
>
> On top of this simple, low-level API, which is identical to our C API,
> I plan to write a set of high-level classes. These classes will make
> it easy to use Subversion to perform common tasks, such as adding and
> removing files from a repository.
>
> Here's an example code snippet, which atomically replaces the "abc"
> branch at "http://svn.collab.net/repos/svn/branches/abc" with a brand
> new copy of trunk. This code snippet is useful for folks who want to
> rebranch in a single atomic commit.
>
> client = Client("http://svn.collab.net/repos/svn")
> txn = client.session().txn()
> client.rm("branches/abc")
> client.cp("trunk", "branches/abc")
> txn.commit("Rebranch the abc branch from the latest revision of trunk")
>
> The above task is significantly easier to implement using csvn
> high-level API than it is using the low-level C API. To implement the
> above functionality using the low-level C API, you would need to drive
> the commit editor by hand, much like mucc does, and this is not
> simple.
>
I think an interface like this is great: it's close to what the user
would do if they were doing the same thing themselves on the command
line as opposed to in code.
> (Note: The above code sample doesn't work yet, because I haven't
> implemented the "cp" function yet in the high-level bindings. Still,
> "rm", "put", and "mkdir" are already implemented and work great. See
> http://csvn.googlecode.com/svn/trunk/example2.py for a working code
> sample.)
>
> Here's a summary of my proposal:
> 1. Replace the low-level SWIG bindings with low-level ctypes
> bindings. Keep the low-level bindings as simple and as similar to the
> C API as possible so that they don't need much maintenance or
> documentation.
> 2. Write some really nice and easy to use high-level bindings in
> Python, so that end users don't need to use the low-level C API. Write
> detailed, friendly documentation for this new API.
>
> Some questions for the list:
> - Should we choose ctypes over SWIG?
I would say yes to ctypes, pending some further investigation/testing.
> - Once high-level bindings for csvn are ready, should we deprecate
> the buggy SWIG bindings, and recommend that users pick csvn instead?
>
Deprecating is fine, but they should still be usable. If all existing
Python/svm code stopped working that would be a big problem. I think
the combination of a recommendation to use the new setup and the
obvious benefits of the new binding will make the choice for a lot of
users.
-Sage
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 10 01:33:40 2007