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

[John Meinel]

Matthew Dempsky wrote:

[...]
> Upgrading in general can be painful for people.  Until a few months
> ago I was still using tla 1.0, because I didn't have any tla packages
> to install (in fact tla on my shell account is *still* 1.0).
>
> Really, how much of a cost is it for someone to wipe their revlibs and
> pristines?  Sure, it might take a while, but surely you won't need all
> of them immediately after updating, and you could write some simple
> scripts to inventory your revlib before and then take care of
> recreating your revlib overnight.

I'm not one to complain. I wipe my revlibs regularly just to save hd 
space. (tlacontrib's shrink-library works very well for this)

> > > 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 a revision library or pristine tree file's inode flags it as
> potentially corrupt, with what do you compare it to determine if the
> file has changed?

Well, my idea would be to keep ctime and use it to detect if more 
processing needs to be done. But an updated ctime would not 
automatically make the revlib considered corrupted. Right now, we are 
using mtime to determine if we need to do a diff, but mtime isn't 
updated by a chmod.

I say, keep both. If the mtime of a revlib changes, it may be corrupt. 
If only ctime changes (and nothing else), just update the inode sig.

During 'tla changes', if ctime of the working directory is newer than 
ctime of the revlib, check the permissions. If mtime is newer, also do a 
diff on the files. If neither show anything (and the revlib is not 
corrupt) touch the revlib to bring the times to the same as the working 
directory, preventing further diffs

[...]
> Emacs supports breaking hardlinks, but if you open a read-only file it
> puts the buffer into read-only mode by default (C-x C-q to change to
> r-w), and when you save it asks if you're sure you want to save a
> write-protected file, and then the new file it creates is still
> read-only.  Just seems irritating to me.

Well, vim does the same thing. I'm not sure how it overrides the write 
protect and then puts it back (I assume it's 2 chmods). I guess the idea 
is that if you were working on system files that aren't generally 
writable, you might override it for a second, but you want it to stay 
write protected.

But it is a hassle for source code.

John
=:->

signature.asc
Description: OpenPGP digital signature