RE: svn commit: r1466183 - in /subversion/trunk/subversion: include/svn_auth.h include/svn_config.h libsvn_subr/auth.c libsvn_subr/auth.h libsvn_subr/config_auth.c libsvn_subr/simple_providers.c tests/libsvn_subr/auth-test.c

> -----Original Message-----
> From: cmpilato_at_apache.org [mailto:cmpilato_at_apache.org]
> Sent: dinsdag 9 april 2013 21:15
> To: commits_at_subversion.apache.org
> Subject: svn commit: r1466183 - in /subversion/trunk/subversion:
> include/svn_auth.h include/svn_config.h libsvn_subr/auth.c
> libsvn_subr/auth.h libsvn_subr/config_auth.c
> libsvn_subr/simple_providers.c tests/libsvn_subr/auth-test.c
>
> Author: cmpilato
> Date: Tue Apr 9 19:13:42 2013
> New Revision: 1466183
>
> URL: http://svn.apache.org/r1466183
> Log:
> Finish issue #4346 ("svn_auth_cleanup_walk() API and friends needs a
> rethink").
>
> Reenvision the svn_auth_cleanup_walk() function and plumbing as a
> generic config-based credential walker that includes the ability to
> trigger a deletion. This seems better match for the extent and
> limitations of the implementation, which is but a mere convenience
> wrapper around the management of Subversion's config-based auth store
> and was never remotely related to "providers" or even "the auth
> subsystem" in a meaningful way. Morever, by associating this logic
> with a specific auth store (our config-based stuff), we can introduce
> new auth stores (e.g., an encrypted store) without being tied to this
> API.
>
> (Don't hate me, rhuijben.)

I tried to encapsulate it in a different way: to allow building a new store and then stil having the same api to delete the entries from the new store.

But this change looks ok. Clients can still remove credentials and most likely the clients that would use this api don't care if they need an update for a future api.

And especially the separate function to clear in memory credentials removes many hacks in the old code... (I didn't like that part of the old code)

        Bert
Received on 2013-04-10 00:07:48 CEST