[MERGE][#230567] Faster (local) branch

[Martin Pool]

On Thu, May 29, 2008 at 12:25 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Robert Collins wrote:
> | On Thu, 2008-05-29 at 11:38 +1000, Andrew Bennetts wrote:
> |> Robert Collins wrote:
> |> [...]
> |>> It was an experimental branch Aaron and I created in London a couple of
> |>> years back; at that time we didn't see a performance gain - but a
> |>> smaller delta now will show up more - we have moved the goalposts a long
> |>> way.
> |>>
> |>> however - os.open() still honours umask, which as I recall is why we
> |>> discarded the branch.
> |> umasks don't cause the execute bit to be set by default, though:
> |
> | Right, but they do prevent the exec bit being set, which means one still
> | needs to do a chmod to be sure it has actually happened (unless we
> | change the umask from within bzrlib, which is somewhat distateful to do
> | as a library).

Ian originally said that he was only chmoding the file if we wanted
the execute bit to be set.  So while it's true that if we _do_ want it
set, we might need to chmod it, I think Andrew and Ian are correct
that if we _don't_ ask it to be set, it will never be set by the os,
and it's redundant to check that it's not.  (Except for things like
vfat where we can't control it at all.)

Anyhow, if the user has set their umask so that it masks off the
user/group execute bits, I don't they can really complain if their
tree has no execute bits.  It would be very weird to have such a
umask.

I think we can avoid doing any chmod operations when building the
working tree.  It seems reasonable to me that it have the permissions
set from the user's umask because that's what their editor, compiler,
etc will also use in creating files in the tree.  All we need to do is
set the exec bit and

> What mode python passes to libc when one does 'file('foo', 'a')' is an
> open question though.

It passes 0666 of course.  Obviously it's not 0777 or everything would be u+x.

(Actually it may be passing nothing at all and libc uses 0666*)

-- 
Martin <http://launchpad.net/~mbp/>

* yum, seitan.