On 4/12/07, David Anderson <dave@natulte.net> wrote:
> On 4/12/07, David James <james@cs.toronto.edu> wrote:
> > Congratulations Sage! It'll be great to have your help.
>
> Indeed, congratulations Sage!
>
> David, I'd just like to repeat that it'd be really nice to get what
> code you already have into a branch in the Subversion repository. It
> doesn't matter if it's not integrated with the build system, hacky or
> incomplete. Having it in the mainline repository will make it easier
> to follow and review as they evolve.
>
> I'm willing to help you do the move if you're currently busy.
I've moved the csvn bindings to
http://svn.collab.net/repos/svn/branches/ctypes-python-bindings/. I've
also added a README file which explains how to build the ctypes
bindings. Hope this helps!
On 4/15/07, Barry Scott <barry@barrys-emacs.org> wrote:
> I take it that you need the CC because you do not follow dev@ all the
> time. Neither do I. Can I suggest a short lived mailing list for those of
> us that want to contribute to this project that will be easier to follow?
If you like, we can setup a separate mailing list and CC it for all of
our discussions, as long as we still send the mails to
dev@subversion.tigris.org so that the Subversion developers are in the
loop. As Dave pointed out, it is always helpful to keep the
dev@subversion.tigris.org list in the loop so that Subversion
developers can contribute.
In any case, I'll make sure that you, me, and Sage are always on the CC list.
> > Barry, I'm hoping to look at pysvn's interface and see what lessons we
> > can learn from your design. I just took a very quick look and noticed
> > that pysvn does not yet support multiple RA operations in a single
> > transaction, so perhaps we can work together on defining an interface
> > for this. You can read more details about my design at
>
> > http://svn.haxx.se/dev/archive-2007-04/0425.shtml
>
> O.k. this is your goals and an outline of the main class behavior.
>
> Is it your intention to ignore the svn client API and build on RA
> and WC?
>
> In apps I do most operations to the WC which needs to be solved
> and if by passing the svn client API means operations like getting
> all the props for the files can work a acceptable performance for GUI
> apps (the svn client API is very slow for this).
>
> It is useful for users to be able to leverage there knowledge of the
> SVN command line to write tools in python. Exposing the svn client
> API pysvn affectively does this.
Currently, the higher-level csvn API doesn't use the SVN client API at
all, because the SVN client API is too limiting. The client API
doesn't, for example, allow us to change multiple files in a single
commit without a working copy.
That said, I hope that users who are familiar with the command-line
client will have an easy time understanding the higher-level csvn API.
I have designed the higher-level API to be as similar to the
command-line client as possible without requiring a WC.
> Please see words and not abbreviations in symbols. Use delete not rm
> use copy not cp. use transaction not txn, etc.
Good point. I've already switched over to using "delete" instead of
"rm" and "copy" instead of "cp". We might want to rename the txn
function to "transaction" as well, as you suggest.
> The svn client API has a bad habit of asserting if user input is
> invalid. pysvn
> protects the python user from problem. Any high level API svn most
> not allow
> the python process to be aborted by an assert just because a string
> does not
> have the right syntax.
+1
> What is the design for authentication? Passing username and password
> to function calls is very limiting given svn's authentication call
> back system.
>
> pysvn allows the defaults for username and password to be set on the
> Client()
> object and that covers a large number of use cases for users.
>
For me, at least, it's easier to specify the username and password as
strings than it is to write callbacks. It's more complex to write a
callback than it is to pass in a simple string.
That said, some applications may want to not specify a username or
password when they open a client session, and instead setup a
callback, so that the user can be prompted when it is necessary. It
should be possible for applications to do this but I haven't designed
the API for this yet.
> The same goes for providing the log message,
> its done via call_get_log_message.
I can't think of any reason off the top of my head why an application
developer would need a callback for log messages. (Can you?)
I think that it is easier for application developers to simply pass in
the log message as a string when they call the "commit" function.
> What is the plan for the API as svn adds features with regards to
> backwards
> compatibility? You will see in the pysvn implementation that I can
> often support
> multiple version of svn's API by adding additional keyword parameters
> to an existing
> function like ls(), but an a certain point svn API will change to far
> and I'll add a new
> function, which happened to support list().
+1
> You might like to try writing the outline of the reference
> documentation and see if the
> design is explainable.
I've already written some basic docstrings for the functions in
http://svn.collab.net/repos/svn/branches/ctypes-python-bindings/csvn,
but I haven't written a design outline yet. For now, you can see the
API by looking at the Repos, Txn, and ClientSession classes in
repos.py, txn.py, and client.py.
I believe that Sage is working on an outline now. When he has
something ready I'm sure he will send out a mail.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 15 23:40:20 2007