Ben Collins-Sussman email@example.com writes:
libsvn_auth is finished, for the moment, as a standalone library.
That is, the internal machinery seems to work, and I've written two
simple (username/password) back-end providers. I have two test
programs (in tools/examples/auth_provider) that demonstrate how to
write new providers.
My only task (from here out) is to make the existing libsvn_client and
libsvn_ra code actually *use* libsvn_auth. But that shouldn't affect
your work at all. I'm not really sure why you'd need a branch.
So by all means, add a new 'certs' credentials type to svn_auth.h, and
create a new certs_provider.c file in libsvn_auth/. You can start
writing the provider now.
The reason it's on a branch is merely that David hasn't been through
the usual commit access process (that is, the patch review process
described in HACKING). The stuff in trunk is the stuff we
collectively vouch for. It doesn't matter whether it's live yet or
not -- if it's in the dist, then people will read it as example code,
maybe try to use it, etc.
Since this is a multi-patch, ongoing change, it would be inconvenient
to post patches to the list, though. Organizing the changes on a
branch is much happier for everyone.
So please keep committing on the branch; it'll get reviewed there just
as if it were patches to the list.
Speaking of which: you might want look over the logs, the HACKING, and
existing code for guidelines on log messages, doc strings, and
For example, this function added in rev 4597:
/* Retrieve a named configuration value, specifying a default.
The configuration will first be checked for a configured default
(in the default group), then will check the specified server
group for an override. If nothing is found in either the default
section or the server section, the default value will be returned
static const char*
const char* server_group,
const char* option_name,
const char* default_value)
const char* retval;
svn_config_get(cfg, retval, default, option_name, default_value);
svn_config_get(cfg, retval, server_group, option_name, retval);
...should give the parameters by name in its doc comment, and align
the asterisks to the right, not the left, in const char *foo (just
as you did one function later, in get_server_setting_int() ).
See the function you removed, get_server_settings(), for an example of
a doc comment. Note that for public interfaces we've switched to
doxygen-style comments; the upcased-params style is still the norm for
internal static functions, but you could use doxygen there too if you
prefer. The main thing is to name every parameter and state precisely
what it does.
This will not only make the changes easier to review, but help someone
trying to understand the code two years later :-).
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 14 02:19:47 2006