Re: svn commit: r27648 - in trunk/subversion: libsvn_repos svnserve

On 11/6/07, kfogeltigris.org <kfogeltigris.org> wrote:
> Author: kfogel
> Date: Tue Nov  6 22:00:47 2007
> New Revision: 27648
>
> Log:
> Documentation changes only.
>
> * subversion/libsvn_repos/repos.h
>   (svn_repos_t.capabilities): Add explanatory note.
>
> * subversion/svnserve/serve.c
>   (find_repos): Anticipate a likely confusion by
changing wording.
>
>
> Modified:
>    trunk/subversion/libsvn_repos/repos.h
>    trunk/subversion/svnserve/serve.c
>
> Modified: trunk/subversion/libsvn_repos/repos.h
> URL: ht
tp://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_repos
/repos.h?pathrev=27648&r1=27647&r2=27648
>
============================================================
==================
> --- trunk/subversion/libsvn_repos/repos.h      
(original)
> +++ trunk/subversion/libsvn_repos/repos.h       Tue Nov
 6 22:00:47 2007
>  -120,7 +120,13 
>
>    /* If non-null, a list of all the capabilities the
client (on the
>       current connection) has self-reported.  Each
element is a
> -     'const char *', one of SVN_RA_CAPABILITY_*. */
> +     'const char *', one of SVN_RA_CAPABILITY_*.
> +
> +     Note: it is somewhat counterintuitive that we
store the client's
> +     capabilities, which are session-specific, on the
repository
> +     object.  You'd think the capabilities here would
represent the
> +     *repository's* capabilities, but no, they
represent the
> +     client's -- we just don't have any other place to
persist them. */
>    apr_array_header_t *capabilities;

Given that it is admittedly counterintuitive, how about
calling the
field client_capabilities?

--dave

-- 
David Glasser | glasserdavidglasser.net | http://www.davidglasser.
net/

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org