I'll add users@subversion.tigris.org so other see the discussion. There
are a number of comments there already.
Barry
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
>client.svn_add().
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
>intuitive).
>We should be more consistent about path vs. path_list. Ideally both would
>work; I should be able to write both of the following:
>
>client.add("foo.c")
>newfiles = ["bar.c", "baz/"]
>client.add(newfiles)
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
>directory.
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"
>client.update(wc)
># make some changes
>client.add("foo.c")
>client.remove("bar.c")
>#add all unversioned files
>changedfiles = client.status(wc)
>client.add([s.file for s in changedfiles if s.status ==
>pysvn.status.UNVERSIONED])
>client.revert("tmp/", True)
>client.commit(wc)
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.
Barry
---------------------------------------------------------------------
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