Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files

[Matthew Dempsky]

Aaron Bentley <address@hidden> writes:

> John Meinel wrote:
>
>> Is there a specific reason why permission changes are not detected?
>
> Not really.  It's planned, but we want to do it carefully, so that old
> signatures still work, and only new ones store the permission data.

Why do we need to worry about old signatures at all?

Is there something wrong with telling people "when you upgrade from
tla $LAST_RELEASE to tla $CURRENT_RELEASE, you will need to delete all
of your revlibs and pristine trees"?  It doesn't cause any harm except
that the user will need to rebuild them.

If it's *really that critical* that they be able to use their existing
inode-sigs, I think they can write (or pay someone to write) a little
script that would update the sigs to the new format.  Only issue is
making sure that permissions are correct which doesn't seem any easier
to check for than by just reconstructing the tree.

>> Also, if checking timestamp, which one are you checking? As I
>> recall, mtime is the last modification to the file, but ctime is the
>> last update of permissions.
>
> We use mtime.  Unfortunately, ctime is modified by operations we wish
> to ignore, like adding hard-links.

Hm, I hadn't realized ctime was updated by hard-links... that really
blows.

If we're going to start including permissions info in the inode sigs
file, we need to decide what to do about ACLs if anything.  I've
talked to a few people who seem to think this is a big deal, but arch
doesn't even "correctly" handle ownership changes in files.  On the
other hand, is there even any way to give good semantics for those
kinds of things in Arch?

I wonder if permissions aren't just outside the scope that arch should
be trying to address anyways.  It would seem ugly trying to
interroperate between two companies where one requires a umask of 077
while the other might have no requirements and everyone just defaults
to 002 or 022.

Yeah, they could do some arch magic like one company tags off a
branch, changes permissions and commits, then has the other company
tree-sync with the revision, but they'll have to repeat that each time
a new file gets added to the source tree.

Does having arch manage permissions do us any good?  Do other revision
control systems try to do this?  Are they considered successful?
Would anyone be opposed to dropping this feature?

(The last question isn't so much a serious proposal, but a
solicitation for feedback on if there are any uses for trying to
manage permissions in a distributed environment.)