Karl Fogel wrote:
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.
Mostly because I'm solving issue 650 in multiple steps. First, I'm
adding server certificate validation in (which is already working - I
just need to have the returned errors provide more context). Second
comes client certificate authentication; this will require the new
libsvn_auth provider. I will hopefully finish the first portion right as
the simple providers are connected.
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.
This is actually the sort of thing I would use distributed branching
for, if it existed ;-)
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.
I tried to go over HACKING and the logs for some examples, basically
admitting to myself that I would at least slightly mess up my first
commit or two. My personal policy for development branches is much more
informal than the main branch, while with the subversion project they
appear to be just as formally reviewed. This caused a slight bit of
internal turmoil. ;-)
For example, this function added in rev 4597:
snip
...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 :-).
Points noted. I will probably switch to doxygen-style in case these
functions someday become part of the public configuration interface.
-David Waite
---------------------------------------------------------------------
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:20:00 2006