On Fri, Apr 5, 2013 at 6:47 PM,  <danie...@apache.org> wrote:
> Author: danielsh
> Date: Fri Apr  5 14:47:37 2013
> New Revision: 1464993
>
> URL: http://svn.apache.org/r1464993
> Log:
> 'svnadmin info': sketch the public API.
>
[..]

Duplicating my comments from IRC inline.

> +typedef struct svn_fs_info_t {
> +
> +  /** @see svn_fs_type() */
> +  const char *fs_type;
> +
> +  /** @see svn_fs_get_uuid() */
> +  const char *uuid;
> +
> +  /** @see svn_fs_youngest_rev() */
> +  svn_revnum_t youngest;
> +
> +  /** Filesystem format number: an integer that increases when incompatible
> +   * changes are made (such as by #svn_fs_upgrade). */
> +  int fs_format;
> +
> +  /** The oldest Subversion GA release that can read and write this
> +   * filesystem. */
> +  svn_version_t *supports_version;
> +
> +#if 0
> +  /* Potential future feature. */
> +  svn_boolean_t is_write_locked;
> +#endif
> +
> +  /** Filesystem backend (#fs_type) -specific information.
> +   * @see SVN_FS_FSFS_INFO_* */
> +  apr_hash_t *fsap_info;
> +
What is the values of this hash table? Always strings? What about
integers or booleans?

> +  /** List of user-serviceable config files.
> +   * Elements are dirents (as const char *). */
> +  apr_array_header_t *config_files;
I don't see real use why config_files information can be useful in
svnadmin info command. So I suggest to remove it until we need it.

> +
> +} svn_fs_info_t;
> +
> +/**
> + * Set @a *info to an info struct describing @a fs.
> + *
> + * @see #svn_fs_info_t
> + *
> + * @since New in 1.8.
> + */
> +svn_error_t *
> +svn_fs_info(const svn_fs_info_t **info,
> +            svn_fs_t *fs,
> +            apr_pool_t *result_pool,
> +            apr_pool_t *scratch_pool);
> +
> +/**
> + * Return a duplicate of @a info, allocated in @a pool. No part of the new
> + * structure will be shared with @a info.
> + *
> + * @since New in 1.8.
> + */
> +svn_fs_info_t *
> +svn_fs_info_dup(const svn_fs_info_t *info,
> +                apr_pool_t *result_pool);
> +
> +/** @name FSFS-specific #svn_fs_info_t information.
> + * @since New in 1.8.
> + * @{
> + */
> +
> +/** Value: shard size (as int), or 0 if the filesystem is
> + * not currently sharded. */
> +#define SVN_FS_FSFS_INFO_SHARDED "sharded"
> +
> +/** Value: abspath to rep-cache.db, or absent if that doesn't exist.
> + @note Do not modify the db schema or tables!
> + */
> +#define SVN_FS_FSFS_INFO_REP_CACHE_PATH "rep-cache-path"
I suggest to replace it with boolean REP_CACHE_ENABLED. In most cases
user is interested wheither rep caching is enabled or not.
rep-cache.db stored in stable location.

[...]

> + */
> +typedef struct svn_repos_info_t {
> +
> +  /** Repository format number: an integer that increases when incompatible
> +   * changes are made (such as by #svn_repos_upgrade). */
> +  int repos_format;
> +
> +  /** The oldest Subversion GA release that can read and write this
> +   * repository. */
> +  svn_version_t *supports_version;
> +
> +  /** Set of basenames of hook scripts which have been installed.
> +   * Keys are C strings such as "post-commit", values are undefined. */
> +  apr_hash_t *hooks_enabled;
> +
> +  /** Set of basenames of hook scripts which are respected by this version of
> +   * Subversion.  Keys are C strings such as "post-commit", values are
> +   * undefined.
> +   *
> +   * @note Hooks are sometimes extended (e.g., by passing additional 
> arguments
> +   * to them).  In the future we might extend the semantics of this hash to
> +   * describe that case, for example by adding keys or defining a meaning for
> +   * the values.
> +   */
> +  apr_hash_t *hooks_known;
> +
Do we really need information about hooks in svnadmin info command?
What is the behavior is hook file is present but empty? I suggest to
remove this information from svn_repos_info_t and implemented as
different API if needed.


-- 
Ivan Zhakov

Reply via email to