Executable flagging patch

[george young]

On Tue, 04 Oct 2005 13:01:12 -0500
John A Meinel <john at arbash-meinel.com> threw this fish to the penguins:

> Aaron Bentley wrote:
> > Aaron Bentley wrote:
>... 
> > Now that I've looked at the changes, I don't think they're enough.
> > commands like revert and merge should modify the x-bit and that alone,
> > but it looks like they would also affect the read/write bits.
> >
> > This is because generate_changeset still uses the ChangeUnixPermissions
> > object, which affects all permissions.  Instead, I think a new
> > ChangeExecuteBit object should be introduced that only affects the
> > execute bit.
> 
> We might also want to have ChangeExecuteBit be aware of what rw bits are
> set. Because you may not want to enable X for a file which does not have
> rw for other.

I strongly believe that a rcs should leave the permissions bits
however the user set them.  It may not *usually* be useful or
appropriate for 'other' to have x but not r, but I really don't think
bzr should be making decisions about what permissions ought to be.
Just do your best to maintain what the user set, and that will be
fine. 
[my appolgies if I have misunderstood the substance of this discussion...]

> Perhaps it is enough to just mask against umask. I didn't see a way to
> get the umask without setting it, but you could do:
> 
> newmask = 0022
> oldmask = os.umask(newmask)
> if oldmask != newmask:
>   os.umask(oldmask)
> 
> newpermissions = oldpermissions | (x_bit & oldmask)
> 
> Though a default of 0022 (which is common on all of my machines) unsets
> the write bit, but not the read or execute.
> 
> I don't really care whether we set all the X bits, or just the user X
> bit. But I thought it should be discussed.
> 
> John
> =:->
> 
> >
> > Aaron
> 


-- 
"Are the gods not just?"  "Oh no, child.
What would become of us if they were?" (CSL)