On Apr 15, 2007, at 22:40, David James wrote:
>
>> > 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.
Just to be clear you do intend to write the code that supports the WC?
And functions like diff between WC and REPOS you will build from the
lower level SVN APIs?
>
>> 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.
pysvn does not require a call back to support username and password.
You do this:
c = pysvn.Client()
c.set_default_username( username )
c.set_default_password( password )
After that all operations will use the username and password. It is not
nessesary to pass in the username and password for each commit.
> 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?)
Its part of the way the SVN API works is the reason. More specifically
I believe this is because when you use the svn_client_XXX functions
its not clear if a commit will happen so SVN calls back to get the log
message if it needs one. For example svn_client_copy on a WC does
not need a log message but one on a REPOS does.
> 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.
This works because you will seperate WC and REPOS actions
and its always clear that a log message is required.
>
>> 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.
>
o.k. I'll find time to do some reading.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 17 21:29:42 2007