On Tue, Feb 12, 2008 at 12:56 +0100, Guido Wesdorp wrote: > holger krekel wrote: > > Transparently inheriting AUTH info might sometimes not be desired > > or be tricky, not sure. I'd try this after all else is done (see below). > > > > > Not sure about this one. If you do a checkout with authentication args, > all children will be checked out with the same credentials. If you later > perform an action on that child that requires authentication, I think > the expected behaviour is that the credentials used for the previous > checkout are used, unless other credentials are provided.
This is what SVN cares for itself by storing credentials in the FS. As to in-process (somewhat implicit) inheritance of auth information: I hold that it might be complicated to get it right and and simple enough. IMO all methods modifying the repo need to accept an explicit auth parameter independently if there also is auth-inheritance-starting-from-constructor going on or not. Due to the many options that an SvnAuth class needs to handle i'd like to avoid cluttering the "parameter namespace" of the svn path constructors. The Constructors are anyway already a bit messy IMO. Also it's easier for testing to encapsulate things in a class and make sure it generates the right command line switches etc. when asked for it. So what about going ahead with implementing this class and using it for the few svnwc methods? The SvnAuth class and the issue of inheritance are orthogonal issues. Therefore much testing and work can be done independently. I suggest we don't discuss much more currently if that is ok with you. holger > >> * Many new arguments required > >> > >> I think it's not very nice to have so many new arguments to the > >> constructors, > >> and especially dislike having an argument that's only useful when other > >> args > >> are provided (auth_cache). Not sure how to improve that, though... > >> > > > > What about a py.path.SvnAuth class ... > > > > > I was thinking about something like that, but figured it would be kind > of heavy for just the SVN auth... However, It's more modular and clearer to test IMO (and will be used both from svnurl's and svnwc's). > > Eventually we might want to generalize SvnAuth slightly > > into some Identity or Auth class that can also be > > used e.g. for py.execnet.SshGateway. > > > > > in that case it may be nice to have, indeed... ;) :) > Then... > > > * then add an explicit 'svnauth' parameter to wc.checkout and wc.commit > > > (which other svnwc methods need it?) > > Well, that depends on the use case. For a repository that requires > authentication for all types of access, if the path objects aren't created > with credentials passed to the constructor, it may be needed for all actions > that hit the server (e.g. update, lock, etc.). hum, but svnwc does not have that many more (than commit/update/checkout/lock) methods that actually go the remote repo, does it? But i haven't checked. > Perhaps it makes more sense to only allow passing auth to the constructor? I > don't really see a use case for using different credentials for different > methods, but I may overlook something? > > Cheers, > > Guido > > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev > -- Holger Krekel - freelance manager and programmer merlinux GmbH: http://merlinux.de py.test: http://pytest.org py lib: http://pylib.org PyPy: http://codespeak.net/pypy _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
