[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-05 05:29:38 CET

On Nov 4, 2004, at 9:53 PM, Greg Hudson wrote:

> On Thu, 2004-11-04 at 15:19, sussman@tigris.org wrote:
>> +/** An opaque object representing a user. */
>> +typedef struct svn_fs_user_t svn_fs_user_t;
>> +
>> +/**
>> + * ### Note: this paves the way for future ACL stuff;
>
> Sorry I tuned out of the IRC conversation when this was proposed.
>
> I don't think we should be paving this much of the way for ACLs. We
> can't give this opaque user concept enough review without a complete
> ACL
> design document. Let's just put a username parameter in svn_fs_lock()
> and svn_fs_unlock() and remove it later when ACLs show up.
>

Unfortunately, it's still more complicated than that. A whole slew of
fs functions -- not just the new lock/unlock funcs -- need to check if
locks exist before changing a path. And that means this whole slew of
functions needs to be aware of some username accessing the repository.
So I still think the idea of "associating a username with an open fs_t"
is necessary.

Maybe we don't need to have this abstract svn_fs_user_t thing that
brane proposed, though. We could simplify by just attaching a (const
char *)username to an fs_t, and leave it at that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 5 05:31:11 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.