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
>
Received on 2014-07-04 00:20:48 CEST