[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Subversion Python bindings

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2003-11-04 17:14:18 CET

I'll add users@subversion.tigris.org so other see the discussion. There
are a number of comments there already.


At 03-11-2003 20:18, John Barstow wrote:
>Attached is a first pass at doc strings for just over half the methods. I
>hope to work on the other half tonight; I also have a HOWTO with common
>workflow tasks in the works.
>In reviewing, I noticed that the ability to relocate the repository seems to
>be missing (svn switch --relocate); this is important when the repository
>URL changes.

O.K. I'll look into it.

Also how is the revision range passed to svn_update? That one for the
rapidsvn folks.

> > What are think a "familiar status code" looks like in python?
> > repr would tell you what it was "<svn_revision_kind_t head>" for example.
>I was thinking of the A, M, ? codes the command line returns. An
>enumeration works better if we add repr.

What is "A, M,"?

O.K. I'll try the enum in a python type and we can see how that works out.

> > What are you thinking of? I think being pythonic is very important.
>Couple of things:
>The svn_ prefix is redundant. I believe client.add() is more pythonic than

I want all commands to have the same naming pattern. If I do not have a
prefix then I end up with one command that is a keyword, "import". There
is a problem in C++ with the "switch" command. The C++ code uses cmd_ as
the prefix.

>The enumerations could be better named(svn_revision_kind_t is hardly
>We should be more consistent about path vs. path_list. Ideally both would
>work; I should be able to write both of the following:
>newfiles = ["bar.c", "baz/"]

O.K. The code is easy, I wonder if there is a down side?

>Having recurse default to False in places where the command line usually
>defaults to True will probably cause problems. It's documented but not
>obvious. It's surprising to do a checkout and only get the top-level

O.K. I'll default all to recurse True. Your the second person to say the
defaults are wrong.

>Lastly, I would expect to pass either a revision number or a revision kind
>to the client api. So:
>client.update("foo.c", 1579)
>client.update("foo.c", revision.HEAD)

The goal of the API is to be obvious to use, extensible and error free to use.
I'm not convinced that adding this sort of short hand is good.

I like the way the keywords make it clear which booleans you are setting.

>As an example, here's the snippet I would like to write:
>import pysvn
>client = pysvn.client()
>wc = "/project/subversion"
># make some changes
>#add all unversioned files
>changedfiles = client.status(wc)
>client.add([s.file for s in changedfiles if s.status ==
>client.revert("tmp/", True)

This requires:
* change the client function names. See above for import problem
* remove keyword recurse from revert. That would be inconsistent.
* support path and lists_of_paths everywhere. Should be reasonable to do.
* find short name for svn enums. removing the svn_ prefix is easy
   but I'm not sure I should remove much more. Over time we may need to
   expose other enums that will conflict with contraction to just status.
   the _t suffix can go as well.
* upper case all enum values. Why did you want the names upper cased?

I'll work on a 0.2 will some of these changes.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 4 17:15:54 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.