Hi Sage,
Nice patch! I looked over your changes and they generally look good. I
found a few places in the example scripts where you forgot to update
references to the old classes, so I fixed these before committing.
In your log message, try to remember to keep a list of the functions
you change. Try also to explain the rationale behind your changes
briefly. Here's an example.
[[[
Rename python classes to make their names more logical. The RemoteRepository
and LocalRepository classes allow direct access to repositories, but don't
allow access to working copies, so it makes more sense to call them
"repository" classes rather than "client" classes.
Patch by: Sage La Torra <sagelt@gmail.com>
(Tweaked by me)
* csvn/client.py:
(ClientURI.__init__, ClientURI.join, ClientURI.dirname,
ClientURI.longest_ancestor, RemoteRepository.__init__,
RemoteRepository._abs_copyfrom_path): Rename ClientURI to RepositoryURI.
Rename ClientSession to RemoteRepository. Rename LocalClient to
LocalRepository. Adjust all callers.
* example.py, log.py, mucc.py, trunkify.py:
Adjust to use new names from client.py.
]]]
I've committed your patch with a few tweaks in r25196.
Dan Rall wrote:
> > ClientURI is now RepositoryURI
> > ClientSession is now RemoteRepository
> > LocalClient is now LocalRepository
>
> RemoteRepository and LocalRepository seem more like RA objects.
That's right. Actually, the local and remote repository classes only
allow direct access to the repository -- they don't let you, for
example, access a WC. Therefore it makes more sense to call them
repository classes, I think.
In the Python bindings, I'm planning to split out our support for WC's
and repositories into separate APIs, so that users can perform client
operations directly on a repository, or on a working copy, as they
please.
It probably also makes sense to write a 'Client' class which wraps the
functionality of the RemoteRepository and WorkingCopy classes into a
single interface for folks who would like to do both with a single
class, but I consider this to be a less important feature.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 30 01:31:21 2007