It would probably be better if you actually proposed an interface for your feature request. Personally, I think that the functions are sufficient, since most of us are used to working with SVN from the command-line.

Patches always welcome, this should be quite trivial to add - have a look at the xmms extension for ideas.

While I can't really give a patch (can't write C, only read it , and not very well), I did some thinking, and I think the main selling point of an object-oriented SVN function would be that it would abstract away the working copy. Classically, SVN functions that operated on your working copy would automatically know what to do based on your current working directory, eg. svn commit would commit the directory it was in: you didn't have to specify that. With svn_commit(), you have to specify the directory, so an "SVN" object would be bound to that working directory so all you'd have to call was $svn->commit(); which might be more logically named $working_copy->commit().

Sorry if I lost anyone there. Still thinking about it.

actually, all other subversion language bindings [1] use an object oriented style. this greatly eases development, and i would very much welcome anything into that direction.

did anyone ever have a look at the feasibility of SWIG [2] php bindings for subversion [3]? this would gain us automatic interface generation, a complete implementation of the subversion apis, less hand-coding, reuse of subversions existing swig infrastructure, and possibly object orientation. unfortunately, my c is worse than my french, so i cannot help directly in implementing this. everyone giving this a try has my moral and testing support, though. thanks a lot!

[1] http://subversion.tigris.org/links.html#bindings
[2] http://www.swig.org/
[3] http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/
[4] http://www.google.com/search?q=subversion+php+swig

swig is broken when it comes to generating PHP code

when did you last check? they seem to have fixed some bugs in the last months [1][2]. and i guess a simple swig php svn binding wouldn't need all of PHPs "advanced" features, thus reducing the "swig is broken when it comes to generating PHP code" further. or is it something fundamental?

[1] http://sourceforge.net/tracker/index.php?group_id=1645&atid=101645&set=custom&_category=379158&_assigned_to=0
[2] http://swig.svn.sourceforge.net/viewvc/swig/trunk/Source/Modules/php4.cxx?view=log

Ah, nice.  Last I looked there was no PHP 5 support and plenty of comments in the source template along the lines of "FIXME, this is totally broken".
I haven't reviewed the actual code in those commits you referenced, but the fact that there is activity there inspires hope and perhaps confidence.

According to the changelog for 0.3, "an OO interface" was added. Does this mean this bug is fixed?

i don't know who closed this issue, but this is definitely wrong. what the 0.3 release does is adding a pseudo static class interface around *four* functions. so instead of svn_checkout(), you can now do Svn::checkout(). same for cat, log, and status - *not* for all the other functions.

this in no way changes the way you can work with this extension. Svn::checkout() still returns bool, Svn::log() still an array of untyped log entries. you don't have any objects (client, revision, working copy, transaction, etc.) to work with - which is what this issue is all about.

for examples of real object-oriented interfaces to subversion, see any of the "object oriented bindings" at http://subversion.tigris.org/links.html#lang_bindings , e.g. http://pysvn.tigris.org/docs/pysvn_prog_ref.html or http://www.softec.st/en/OpenSource/ClrProjects/SubversionSharp/GettingStarted.html .

please re-open.