Gale, David wrote:
...
> 1) On commit, each file's permissions should be stored.
> 2) On checkout, the file should be set to match the stored permissions.
...
> 3) svn status and svn update should recognize changed permissions as a
> change to the file, and respond accordingly.
ACLs aside, I don't really like the idea of doing an implicit permissions change
upon a commit. In my experience, it's common for files in working copies to
have their permissions changed without intending a change to the version in the
repository. Various editors don't always preserve permissions, users may want
to feed their program through a pretty printer first, and the permissions for
development may be totally unrelated to the permissions for deployment.
Conversely, it's not very common to want to change the permissions as far as the
repository is concerned, and hence it's ok if it takes a bit of work.
ACLs make things worse. (OK, I lied about setting them aside.) In Windows (and
imagine most other ACL systems, ACLs can be inherited from parent directories.
So users Pat and Leslie who are pair programming may have their working copy set
to allow both of them to edit the files (i.e. an ACL that explicitly contains
their names), while others just rely on owner permissions. Do you change
permissions every time it gets checked in, based on the inherited permissions?
I think not. On the other hand, if someone is adding a brand new file, it may
not have any of its own permissions; they're frequently all inherited. And so on.
I think it makes more sense just to have explicit actions to change permissions
as far as the repository is concerned. In theory, one could set permissions via
properties, and have something to parse and set them upon checkout. One could
even have platform-specific permissions (e.g. svn::perm::unix and
svn::perm::windows). The content could be in formats convenient for the given
platform, so that the native commands could be used to import and export them.
This could even be taken a step further, by having plug-ins to cope with
additional platforms (e.g. Apache permissions). If and when client-side
triggers become reality, that might be an ideal way to implement this mechanism,
or at least prototype it.
> 4) If a user doesn't have the ability to set permissions, a warning
> should be issued & the file created according to the user's umask.
Do you mean in the repository or the working copy? I'm not familiar with any
way a user couldn't have the ability to change permissions on a file he created,
so I don't understand this point.
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Dec 25 01:04:47 2005