[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]