[svn r52001] Removed (outdated, and perhaps a bit too verbose) document about svn auth, in

favour of a short note and code example in the existing path.txt doc in docs.

--HG--
branch : trunk

py/doc/path.txt

@@ -187,6 +187,23 @@ properties in an :api:`py.path.svnwc` instance::
   >>> len(wc.status().prop_modified)
   0
 
+SVN authentication
+++++++++++++++++++++++
+
+Some uncommon functionality can also be provided as extensions, such as SVN
+authentication::
+
+  >>> auth = py.path.SvnAuth('anonymous', 'user', cache_auth=False,
+  ...             interactive=False)
+  >>> wc.auth = auth
+  >>> wc.update() # this should work
+  >>> path = wc.ensure('thisshouldnotexist.txt')
+  >>> try:
+  ...     path.commit('testing')
+  ... except py.process.cmdexec.Error, e:
+  ...     pass
+  >>> 'authorization failed' in str(e)
+  True
 
 Known problems / limitations
 ===================================

py/path/svn/auth.txt

@@ -1,77 +0,0 @@
-SVN authentication support
-==========================
-
-This document describes authentication support for both py.path.svnwc and
-py.path.svnurl (yet in its implemention phase). This feature allows using the
-library in a completely automated fashion, without having to provide svn
-credentials interactively.
-
-Current implementation
-----------------------
-
-The credentials are passed to the constructor of the path objects, and are used
-(transparently) for every action that accesses the server. Also, when provided,
-they are passed recursively to all child objects created by methods such as
-join(), ensure(), etc. (XXX currently only true for svnurl, not for svnwc)
-
-To pass credentials to path objects, an SvnAuth class needs to be created to
-hold them. This is then passed to the constructor or methods as the 'auth'
-keyword argument. (XXX the latter currently only for svnwc, and preferrably
-that needs to be removed in favour of an .auth attribute like in svnurl)
-
-It is configurable whether the credentials are stored on disk. Storing them is
-useful in certain situations (executive access to the repository will not
-require the credentials to be passed) but might not be desired in others - for
-instance if a webserver runs more than one application, one does not want to
-pollute the webserver's home directory (if it even has one). This behaviour can
-be controlled by passing a False value for the 'cache_auth' argument to
-SvnAuth.
-
-Also it is configurable what behaviour is displayed when the credentials do not
-validate: if a keyword argument to the SvnAuth constructor called 'interactive'
-has a True value (which is currently the default (XXX I think this should be
-changed!)), an interactive prompt is displayed - this is useful for terminal
-applications where you want to have an interactive fallback. When this has a
-False value, an exception is raised (XXX define the exception properly).
-
-Code examples
--------------
-
-So, tying this together, code using this feature would look something like::
-
-  >>> auth = py.path.SvnAuth('user', 'pass', cache_auth=False,
-  ...                        interactive=False)
-  >>> wcpath = py.path.svnwc(path, auth=auth)
-  >>> urlpath = py.path.svnurl(url, auth=auth)
-
-Open issues
------------
-
-* How do we deal with externals properly?
-
-  It looks like the svn command-line client uses the credentials provided for
-  all externals, if possible, and either prompts for the password in
-  interactive mode, or barfs when --non-interactive is passed. I think it makes
-  sense to copy its behaviour here, pass the credentials to any child svn path
-  objects (as discussed above), and either let the command-line app ask for
-  creds or throw an exception when 'interactive' is set to False (see above).
-
-  Current idea: ignore this and let the client handle (so no passing auth
-  around to the children).
-
-* Affected methods for svnwc:
-
-  - switch
-  - checkout
-  - update
-  - lock
-  - unlock
-  - diff (when using older revisions?)
-  - commit
-  - log
-  - status (for locking, etc.?)
-
-* Affected methods for svnurl:
-
-  not appropriate - the auth is passed to the constructor rather or set to
-  path.auth rather than passed to all methods