I'll mention a few more suggestions about improvimg the 'svn auth' UI. Daniel Shahaf wrote on 28 June:
> 'svn auth' URL-escapes and path-canonicalizes the pattern, which breaks some > use-cases. [...] > % $svn auth "<https://svn.apache.org:443> ASF Committers" > DBG: Pattern 0 is '%3chttps://svn.apache.org:443%3e%20asf%20committers' [...] > That's due to using svn_cl__args_to_target_array_print_reserved() [...] > > Seems to me we should just take the patterns from argv as-are, with no changes > save for transcoding (C encoding -> UTF-8). +1. Makes sense to me, at least as an initial step. If we want a more controlled way to search for (part of) a URL without regard to canonicalization differences, then that's something we could add, but not by blindly treating a general pattern as a URL. > [1] As an aside, why did it downcase "ASF Committers"? Did svn think those > words were part of the hostname? I'm on Linux, on a case-sensitive > filesystem. (I guess the URI parser treated "443> ASF Committers" as the port specifier. Why that should be down-cased I don't know.) Some more comments and suggestions. The help says: [[[ auth: Manage cached authentication credentials. usage: 1. svn auth [PATTERN ...] usage: 2. svn auth --remove PATTERN [PATTERN ...] With no arguments, list all cached authentication credentials. Authentication credentials include usernames, passwords, SSL certificates, and SSL client-certificate passphrases. If PATTERN is specified, only list credentials with attributes matching one or more patterns. With the --remove option, remove cached authentication credentials matching one or more patterns. If more than one pattern is specified credentials are considered only they match all specified patterns. Patterns are matched case-sensitively and may contain glob wildcards: [...] ]]] These two sentences in the help are inconsistent: "If PATTERN is specified, only list credentials with attributes matching one or more patterns." "If more than one pattern is specified credentials are considered only they match all specified patterns." (And there's a missing "if" in that last sentence.) Suggestions: Rather than an implicit OR or AND relationship, specify patters using the '--search' and '--search-and' options that are used with 'svn log'. The kind of search available is then that an entry matches: (P1 and P2 [and ...]) or (Q1 and Q2 [and ...]) [or ...] The corresponding arguments would be: --search P1 --search-and P2 --search Q1 --search-and Q2 Since we already have this UI syntax for 'svn log' it would seem sensible to re-use it. The no-arguments form of the command currently means "list everything in the auth cache". For me this produces several pages of not very interesting output. Many of the entries look like these: ------------------------------------------------------------------------ Credential kind: svn.simple Authentication realm: <http://127.0.0.1:6244> Slave Sync Repository Username: svnsync ------------------------------------------------------------------------ Credential kind: svn.simple Authentication realm: <http://127.0.0.1:32340> Slave Sync Repository Username: svnsync ------------------------------------------------------------------------ Credential kind: svn.simple Authentication realm: <http://127.0.0.2:9296> Subversion Repository Username: svnsync ------------------------------------------------------------------------ Credential kind: svn.username Authentication realm: 0ae92485-7cf5-409c-8bf0-b23409813abc Username: jfoad ------------------------------------------------------------------------ Credential kind: svn.username Authentication realm: a234dbc8-65dd-4788-820c-3291b73290db Username: username ------------------------------------------------------------------------ Credential kind: svn.username Authentication realm: 5a9b881f-6758-4d55-8b19-09f827546be1 Username: ------------------------------------------------------------------------ Sure, it's information that is sometimes useful, but do we really want to reserve the no-arguments command for that? I suggest not. I think it would be better if one had to specify something like "--search=*" or "--list" or "--all" to get a full list. There are many things one might like to use 'svn auth' command for. We might want to use the no-arguments form, later, to mean something like "show me the authentication in use for the Subversion WC in the current working directory" or "re-authenticate to the repository in the current working directory". Finally, I'm wondering if "svn authn" as I fear "svn auth" will be confused with "authz" and with "author". - Julian
