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

[John Meinel]

Matthew Dempsky wrote:
> Aaron Bentley <address@hidden> writes:
>
>
> 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.

Well, I know for archives you want to be very careful. I think for 
revlibs, the only thing we would need is for inode sigs to be forward 
compatible. Meaning 1.2.2 can read 1.2.0 sigs, but 1.2.0 can't read 1.2.2.

I think the idea about saving trees is that some people might have slow 
downloads, or large revlibs, and wiping them out and restarting is a 
little painful.

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

Well, I think it was mentioned earlier that one thing the inode checking 
code should do is update the inode sig if it finds that nothing truly 
changed. It could do this for ctime as well. If 'tla changes' found that 
there was no change in a file, the revlib should be brought up to date, 
and 'tla changes --link' can create the hard-links, and then update 
their ctime. Maybe not, as a hard-link could go back across many patch 
levels. But if ctime is just a flag that you need to check for 
corruption, rather than a hard-fast indication of corruption, then if it 
gets updated, the next time you do a check, you make it match.

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

From my understanding, the only "important" permission to keep track of 
is the "executable" bit. So that when I write a script, it will stay 
executable between checkin/checkout.

All other bits seem arbitrary, as they seem more site-dependent. (On my 
working tree, I might want 664/775, but in public_html, I want 644/755)

As far as "ownership". That is something you definitely *do not* want. 
If I check something into my tree, and you check it out, you should be 
the owner. My user most likely does not exist on your machine, and you 
wouldn't have the right to modify a file, or possibly even read it.

The other advantage of only paying attention to the X bit is that you 
can check out trees in "read-only" mode, which works pretty well for 
hard-linked trees, just in case you editor doesn't support breaking 
hardlinks.

John
=:->

signature.asc
Description: OpenPGP digital signature