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

Re: svn commit: r11750 - branches/locking/subversion/include

From: Branko ─îibej <brane_at_xbc.nu>
Date: 2004-11-05 02:07:44 CET

sussman@tigris.org wrote:

>+ * ### Note: this paves the way for future ACL stuff; someday a user
>+ * object can contain information about group membership, and so on.
>+ * Because it's an opaque type, we can easily add new fields and
>+ * create new accessor and setter functions.
>+ */
I'd like to clarify this "ACL stuff". Because we must model our ACLs to
be compatible with the DAV ACL spec, we need an easy way to ask if the
current FS user belongs to a particular group (because an ACL entry
might refer to a group, not the user explicitly). The FS doesn't care
where those group membership mappings come from, so as far as its
concerned, a list of groups would suffice.

However, there are lots of ways to map a username to a group; various
PAM mechanisms on Unix, Apache's auth methods, Windows user info, DAV
principal trees, etc. etc. Because of that it is quite reasonable that
we can't simply add a list of groups to this struct, but rather a
callback function that can answer the question, "is this user in that

Of course, none of this means there's anything wrong with the opaque
struct approach. I just want to point out that this simple struct may
well become a lot more complex later on.

Ah yes, it might be a good idea to note in the docstring that the
lifetime of svn_fs_user_t objects must be the same or longer than the FS
object's lifetime.

>+svn_error_t *svn_fs_lock (svn_fs_lock_token_t **token,
>+ svn_fs_t *fs,
>+ const char *path,
>+ svn_boolean_t force,
>+ long int timeout,
Is there any reason why this can't be apr_interval_time_t?

-- Brane

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 02:07:48 2004

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.