Greg Stein <email@example.com> writes:
> On Wed, Mar 27, 2002 at 03:45:55PM -0500, Greg Hudson wrote:
> > On Tue, 2002-03-26 at 20:48, Greg Stein wrote:
> > > The posix perms aren't very portable, but truth be told, neither is the
> > > executable bit :-) When we write files, we typically turn on "all bits" and
> > > let the umask set them properly.
> > Is there any compelling reason we shouldn't implement this feature just
> > because it isn't portable? Obviously, we'd have to ignore the
> > properties on platforms which can't implement them, but I don't see why
> > that means we should discard the idea entirely.
> Not really sure. We discussed this a couple months ago or so, but I don't
> recall the details of the thread on why we simplified down to just the
> executable bit. I know that I preferred that position, but I honestly can't
> provide a solid user/technical reason for that basis.
Part of my own reason for originally wanted NO perm versioning, and
then conceding that the execute bit would be an okay thing, is bad
experiece with CVS.
Specifically, I have some cgi scripts and such that I keep under CVS
and use on various machines, machines whose httpd setups require
different things from cgi scripts (some run as my userid, some run as
nobody, etc). So on some machines, files that written-to/read-by my
scripts, most of which I *also* keep versioned, need to be world
writable/readable, and on some machine only readable/writable by
myself. CVS *always* screws this up, removing bits were they are
needed and adding them where they aren't. This *really* annoys me.
So, initially my thoughts were very simple -- what business is it of a
version control system to pay attention to file perms, which in my
opinion are more like OS metadata than file attributes?! However, I
have since yielded grounded over the execute bit, though I still am
not a proponent of even that.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 27 22:28:36 2002