You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2003/11/01 10:47:23 UTC
pysvn 0.1.1 Python interface to Subversion released for review
and testing
pysvn is a Python interface to the Subversion client functionality.
It is available in source and win32 binary kits from
http://www.barrys-emacs.org/pysvn/.
The main purpose of this release is to get feedback on the API design.
pysvn should be all you need to use subversion from python. Let's
keep replies on users@subversion.tigris.org please.
Is it pythonic enough? What functionality is missing?
On the missing functionality I have:
* subversion version info e.g. 0.32.1
* property set, get, update, list
John Barstow has kindly offer to help and we will be improving the
documentation.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pysvn 0.1.1 Python interface to Subversion released for review
and testing
Posted by "Jens B. Jorgensen" <je...@tallan.com>.
Barry Scott wrote:
> At 01-11-2003 15:57, Gareth McCaughan wrote:
>
>> Do we need the "svn_" prefixes everywhere? All these things
>> are already in the "pysvn" module, after all.
>
>
> I find that I keep on having to refer to the C code to figure out things
> and the one-to-one naming of enums may make things easier.
I'm with Gareth on this one. The extra prefixes are annoying.
--
Jens B. Jorgensen
jens.jorgensen@tallan.com
"With a focused commitment to our clients and our people, we deliver value through customized technology solutions."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pysvn 0.1.1 Python interface to Subversion released for
review and testing
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 01-11-2003 15:57, Gareth McCaughan wrote:
>Do we need the "svn_" prefixes everywhere? All these things
>are already in the "pysvn" module, after all.
I find that I keep on having to refer to the C code to figure out things
and the one-to-one naming of enums may make things easier.
>Class names in Python generally have initial capital letters: pysvn.Client,
>pysvn.Revision.
O.K.
>It would be nice to have less cumbersome ways of constructing
>a pysvn.revision object.
>
> # might actually be better to make this map names to already-made
> # revision objects.
> _kind_map = { "head": opt_revision_kind.head, <etc> }
>
> def rev(special=None, date=None, number=None):
> if (special is None) _ (date is None) + (number is None) != 2:
> # complain: exactly one should be passed in
> if special:
> return Revision(_kind_map[special])
> if date: return Revision(opt_revision_kind.date, date)
> if number: return Revision(opt_revision_kind.number, number)
If I lose the enums and use strings for kind I'd have the same interface.
>It would be nice (I'm not sure whether it would be *good*) to allow
>a string to be used as a revision date, to be parsed using time.strptime.
I don't think string formats is the business of pysvn.
Just call time.strptime on your string and pass in the float time.
>I don't like seeing member variables exposed as part of the documented
>interface of a class. Especially not for setting. Especially-squared not
>when there's no cause for them ever to change after construction.
>So I'd advise losing the last two examples of the use of the pysvn.revision
>class.
The class is implemented completely in C++ no internals are exposed.
I could make them read-only properties after construction.
>For reasons of efficiency, svn_client_revert may be about to change
>so that it takes a list of paths. If not, then it's likely that a new
>function that takes a list of paths and reverts them all will be
>added. In either case, you'll want to support that.
That will be easy to support.
>What happens when one of these svn_xxx functions returns? Do you
>return a wrapped svn_error_t, or do you never return anything and
>raise an exception when something goes wrong? I'd vote for the latter.
You see a RuntimeError exception with the text of the svn_error_t in it.
I need to add a ClientError exception rather then use RuntimeError.
>Some of these functions have a "recurse" argument that defaults to
>False, where the corresponding svn subcommand defaults to recursing.
>That might be confusing.
I used the default from the svncpp C++ code as far as I remember. They
think its better to default recurse off. In a GUI the recurse is not
required, in a CLI replacement it is required.
>There are a lot of arguments called "path". Can they take URLs pointing
>into repositories as well, where appropriate?
If svn supports a url in the path args then yes. I've used the
naming from svncpp.
>--
>Gareth McCaughan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
moved files showing up in two places on checkout
Posted by Bill Comisky <bc...@pobox.com>.
I just noticed I had a discrepancy between my main working copy and newly
checked out working copy.
Here's the scenario that lead to this.
1) I moved some files (via "svn mv") from one versioned
subdirectory (dirA) to another (dirB), then comitted (Rev 158).
2) I *think* I did an "svn up".. actually I would've gotten an
"out-of-date" on my next commit (see below) if I hadn't right?
3) I then renamed the original dirA with "svn mv dirA newA" and comitted
that change (Rev 159).
4) svn up
In the WC where I did all of this, I see the originally moved files only
in dirB. However, if I do a new checkout, I see the files in dirB and in
newA.
"svn st -vu" in the newly checked-out working copy (in directory
newA) shows:
...
178 138 bcomisky runpar.m
178 147 bcomisky runmpm.m
178 159 bcomisky celldir.m
178 159 bcomisky cassegrain.m
...
The first two files shown should have been moved to dirB in Rev 158 and
they don't show up in newA in my original wc (even after "svn up" etc).
In the newly checked out wc in dirB, "svn st -vu" gives:
...
178 158 bcomisky runpar.m
178 168 bcomisky runmpm.m
...
The second file shown was modified after it was moved in Rev 158. The
"svn st" output from my original wc in dirB matches this.
The original moves where done over http: using 0.30.0 of the Subversion
client and server. I updated to Rev 7592 of the Subversion trunk last
night for both client and server, which didn't change anything.
Did I screw up somewhere? What operations could lead to something like
this? Can I just "svn rm" the old files from newA in a newly checked out
WC? Is my original WC hosed?
bill
--
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pysvn 0.1.1 Python interface to Subversion released for review and testing
Posted by Gareth McCaughan <ga...@pobox.com>.
On Saturday 01 November 2003 10:47 am, Barry Scott wrote:
> pysvn is a Python interface to the Subversion client functionality.
> It is available in source and win32 binary kits from
> http://www.barrys-emacs.org/pysvn/.
>
> The main purpose of this release is to get feedback on the API design.
[I haven't yet looked at the actual code, only at the docs.]
Do we need the "svn_" prefixes everywhere? All these things
are already in the "pysvn" module, after all.
Class names in Python generally have initial capital letters: pysvn.Client,
pysvn.Revision.
It would be nice to have less cumbersome ways of constructing
a pysvn.revision object.
# might actually be better to make this map names to already-made
# revision objects.
_kind_map = { "head": opt_revision_kind.head, <etc> }
def rev(special=None, date=None, number=None):
if (special is None) _ (date is None) + (number is None) != 2:
# complain: exactly one should be passed in
if special:
return Revision(_kind_map[special])
if date: return Revision(opt_revision_kind.date, date)
if number: return Revision(opt_revision_kind.number, number)
It would be nice (I'm not sure whether it would be *good*) to allow
a string to be used as a revision date, to be parsed using time.strptime.
I don't like seeing member variables exposed as part of the documented
interface of a class. Especially not for setting. Especially-squared not
when there's no cause for them ever to change after construction.
So I'd advise losing the last two examples of the use of the pysvn.revision
class.
For reasons of efficiency, svn_client_revert may be about to change
so that it takes a list of paths. If not, then it's likely that a new
function that takes a list of paths and reverts them all will be
added. In either case, you'll want to support that.
What happens when one of these svn_xxx functions returns? Do you
return a wrapped svn_error_t, or do you never return anything and
raise an exception when something goes wrong? I'd vote for the latter.
Some of these functions have a "recurse" argument that defaults to
False, where the corresponding svn subcommand defaults to recursing.
That might be confusing.
There are a lot of arguments called "path". Can they take URLs pointing
into repositories as well, where appropriate?
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pysvn 0.1.1 Python interface to Subversion released for review
and testing
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sat, 2003-11-01 at 04:47, Barry Scott wrote:
> pysvn is a Python interface to the Subversion client functionality.
> It is available in source and win32 binary kits from
> http://www.barrys-emacs.org/pysvn/.
Cool! But all I see are zip files.... where's the repository URL? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: pysvn 0.1.1 Python interface to Subversion released for review and testing
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Nov 1, 2003, at 5:47 AM, Barry Scott wrote:
> pysvn is a Python interface to the Subversion client functionality.
> It is available in source and win32 binary kits from
> http://www.barrys-emacs.org/pysvn/.
>
> The main purpose of this release is to get feedback on the API design.
> pysvn should be all you need to use subversion from python. Let's
> keep replies on users@subversion.tigris.org please.
>
> Is it pythonic enough? What functionality is missing?
Neat. The only thing that seems non-pythonic is the continued use of
things like pysvn.svn_wc_status_kind.absent. It seems like the
svn_wc_status_kind part could be made into something that's less vocal
about it's c roots. Other than that this whole thing looks really
really cool. Good work!
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org