gnu-arch-users
[Top][All Lists]
Advanced

[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: Matthew Dempsky
Subject: Re: [Gnu-arch-users] BUG: feature request: 'tla chmod' which 'touch'es files
Date: Sun, 26 Sep 2004 02:30:19 -0500
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

John Meinel <address@hidden> writes:

> Matthew Dempsky wrote:
>> 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.

No, you're missing the point.  What could you possibly do during that
"more processing" to actually determine if the revlib is corrupt?

Right now if the mtime is wrong, then *your revlib is corrupt*.
That's it.  Game over.  Give up.  Delete that revlib and recreate it.
There's no diff computed to check that maybe it's just a false
positive because there's nothing to compute it against!

The whole point of the revlib is to be an authoritative reference
point for files from a specific revision.  If one of those files has
been possibly altered, we have no files to possibly compare it to
unless we recreate the revision from changesets.

And if we do that to check revlib validity, why not just purge the
revlib and recreate it?

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

No one ever said we were getting rid of the current inode sig values;
just possibly supplementing them to support permissions.




reply via email to

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