Julian Foad wrote on Thu, Jul 03, 2014 at 13:51:49 +0100: > 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. >
Okay, filed http://subversion.tigris.org/issues/show_bug.cgi?id=4513 > > [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. > > 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. > I wonder if it would be a good idea to have a lispish expression parser there? as in --search-lisp "('or ('and P1 P2) ('and Q1 Q2))" > 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". > I'm not sure whether your output is representative or an artifact of you being an svn developer, but in any case, making 'svn auth' with no arguments an error --- for now, so that we can assign it a meaning later --- would get my vote. > Finally, I'm wondering if "svn authn" as I fear "svn auth" will be > confused with "authz" and with "author". > Poll users@ ? Daniel > - Julian >
