Executable flagging patch

[Martin Pool]

On 05/10/05, george young <gry at ll.mit.edu> wrote:
> On Tue, 04 Oct 2005 14:14:22 -0500
> John A Meinel <john at arbash-meinel.com> threw this fish to the penguins:
> > george young wrote:

> > > 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...]

> Bzr should preserve permissions bits just as slavishly as "tar".  Ok,
> if a file lacks owner+r or a directory lacks owner+rwx, this prevents
> bzr from doing it's job, so we can just punt with a rude error
> message.  Otherwise, it should maintain permissions just as they are.
> (I believe tla(gnu-arch) does this [it even seems to have some code
> for preserving setuid, setgid, etc.])

But this seems to contradict your previous message that bzr should
leave the permission bits alone.  arch had the behaviour that if i did
'tla update', permissions might change from 0644 to 0600.  I think
that's not a good default behaviour (though it might be useful in
particular cases).  Or maybe I misunderstood what you meant by "leave
them alone".

I guess we should avoid having the 0001 bit set on branches which are
not meant to be publicly readable.  It seems reasonable to me to do
that using either the umask or the existing permissions of the file.

--
Martin