On Mon, Nov 11, 2013 at 02:39:26PM +0000, Philip Martin wrote:
> Stefan Sperling <stsp_at_elego.de> writes:
> > The proper way of clearing the 'x' bit would be to remove
> > the svn:executable property.
>
> That removes all x. The r1537018 fix allows users to remove just
> group/world permissions and have Subversion preserve that change.
Well, 'preserve' in the sense that it is preserved in the working copy
only. These bits are not versioned.
> It appears the same is not possible with x. And if I try to do it by
> removing svn:executable and setting x just for the owner then commit
> removes x.
The 'x' bit is a versioned entity, so it needs to be preserved across
working copies. I think that is the crucial difference.
I cannot really see why someone would in general want to have 'rx' set
for the owner, and 'r' set for group/others without 'x'. That makes no
sense. If others may read the file, they can just make a copy of the
file executable and run that. There might be valid use cases for this,
but here we're starting to enter "full permission bits versioning"
territory which we don't declare to support. We support just the 'x' bit.
It's a clutch, but that's what I make of the current sitation.
In any case, the pre-r1537018 behaviour was worse and not intended.
> > As long as that property exists I think we should restore the 'x' bit
> > for users who have read access to the file. If svn:executable isn't
> > set I would expect svn to leave the x' bit alone.
> >
> > However, because we have no svn property to control 'r' and 'w' bits
> > I think we shouldn't mess with them on existing files.
>
> We have some control over w via svn:needs-lock.
True. Good point. That is a side effect of how Subversion attempts
to alert other tools about a non-locked file. It's yet another
factor that toggles permission bits, but it's actually unrelated
to the idea of versioning permission bits.
> > The umask should affect newly created files only.
> > It is a problem to apply the umask to existing files because users
> > might not want that at all (hence the r1537018 nomination).
>
> So the desired behaviour is to let users set r/w different from umask
> and preserve it, but not to preserve x different from umask?
Yes. In other words, I guess we could say that the umask only affects
bits which aren't controlled by svn:executable or svn:needs-lock?
Note again that I think we should only take umask into account for
newly created files if possible. I'm not sure how consistent the
current behaviour is in that respect.
> But we do
> preserve x different from umask if combined with r different from umask.
Yes, since the file is explicitly versioned with an 'executable'
attribute. In Subversion's current model where we only version the
'x' bit, I don't see a way of expressing it better than that the 'x'
bit gets set/cleared for all 'r', depending on the 'executable' attribute.
> I'm not claiming that behaviour would be right or wrong, just that I'm
> not clear what is intended.
Same here :) I think we're running into loosely specified behaviour
that results from Subversion's approach of versioning a subset of
permission bits. But changing that basic assumption is more involved
than the r1537018 fix and clearly out of scope for a patch release.
Received on 2013-11-11 16:06:02 CET