|
From: | John Meinel |
Subject: | Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files |
Date: | Sun, 26 Sep 2004 01:04:06 -0500 |
User-agent: | Mozilla Thunderbird 0.8 (Windows/20040913) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |