Justin Erenkrantz wrote:
>I'm currently playing with importing my home directory into SVN
>and the one thing that I really need to have is being able to
>declare a file as "read-only", "write-only" (of course, executable
>is already present). And, I would also like to extend this to
>the traditional Unix model of ugo. My umask wouldn't work as
>each file has explicitly different permissions.
>
>A property like svn:protection="600" which would then just call
>apr_file_perms_set() would do the job (perhaps the octet values
>wouldn't be the cleanest way, but it'd work). Of course, on OSes
>where APR would return APR_INCOMPLETE or APR_ENOTIMPL, that would
>not be treated as a fatal failure. But, at least the client has
>enough knowledge to know what the right perms should be. (I'd
>guess the default would be not to have this gathered from an import,
>but allow the user to do a propset on this, but of course, we know
>the original modes on an import or add.)
>
>Of course, I'm willing to code this up, but before I do, I'd like
>to throw it out there for any thoughts or concerns. -- justin
>
>
Well, the first thought and concern is that this is extremely
Unix-centric -- but I guess you're aware of that. :-) The second thing
that comes to mind is that, to make this complete, you'd have to store
the file's owner and/or group, too.
All of which leads towards storing and restoring ACLs.
So: +0 if you can come up with a generic way to describe a file's ACL,
and use that, even if it's initially only used for Unix permission bits.
If it can be used to version NT ACLs and various Unix ACL flavours, I'd
be quite happy. (You do realize, of course, that if you go this way,
then sooner or later ther'll have to be a generic ACL API in APR, too --
but then, you're just the right person to design something like that. :-)
And: -0.5 if you just want to add another Unix-specific property that
stores just basic Unix permission bits.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 21 17:14:11 2002