I'll add firstname.lastname@example.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
O.K. I'll look into it.
Also how is the revision range passed to svn_update? That one for the
> > 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 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:
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:
>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 ==
* 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 4 17:15:54 2003