Inspired by the ongoing '[DESIGN] mtime versioning - was: Getting Bug
1256 fixed' thread, I'd like to put forth the following, mainly because
it's mentioned in passing in bug 1256, and not (as far as I can tell) in
any other bug in the issue tracker.
Requirement: Preserve file permissions on checkout.
Intention: An expansion of the functionality currently provided by the
svn:executable property, to allow files to retain the exact permissions
they're committed with. Some files need to be read-only for certain
processes to work, some need to be globally editable, some need to have
the sticky bit set, etc.
Terminology: Since permissions apply to files and directories, I will
henceforth use 'file' to refer to both unless specifically indicated
otherwise.
Details:
- NOTE: UNIX and Linux files have a fairly wide range of permissions
possibilities. Windows is more limited (something is read-only or it
isn't; there is no executable flag that I'm aware of). I don't know
about Macintosh permissions; perhaps someone else can speak to this.
1) On commit, each file's permissions should be stored.
2) On checkout, the file should be set to match the stored permissions.
a) If checking out to a system (such as Windows) that doesn't support
the full set of permissions, any non-applicable permissions should be
ignored. (Thus, a read-only file remains read-only, even if there is no
executable bit).
b) These ignored permissions should still be "present" and, ideally,
editable by the user, so as to not break permissions when developing
cross-system.
3) svn status and svn update should recognize changed permissions as a
change to the file, and respond accordingly.
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.
5) The only issue I can think of is with svn:needs-lock, since it
overrides the standard permissions processes. I would propose having
svn:needs-lock continue to function as current (toggling between the
"official" permissions as stored in the file permissions property and a
read-only equivalent), with a special override flag to svn update and
svn checkout to allow checking out to/updating a production system
without svn:needs-lock automatically making the file read-only.
My best thought for the actual "how" of the implementation would be as a
property, as that automatically fulfils points 1, 2b, and 3.
Note that this would deprecate svn:executable.
Comments?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 28 20:37:59 2005