[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue 650, SSL certificate authority validation questions

From: <kfogel_at_newton.ch.collab.net>
Date: 2003-01-27 17:15:40 CET

Ben Collins-Sussman sussman@collab.net 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
formatting conventions.

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*
   get_server_setting(svn_config_t *cfg,
                      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);
     if (server_group)
       {
         svn_config_get(cfg, retval, server_group, option_name, retval);
       }
     return 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 :-).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:19:47 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.