Re: [Gnu-arch-users] Re: tla on nfs only

[Stefan Monnier]

>>> For each file, The first check tla does is stats against the revision
>>> library.  This is the cheapest check it can do.  If the files are
>>> hardlinks of each other, the working copy hasn't changed.
>> In my world, this *never* happens, so it's a complete waste of time.
> In my world, it's faster.

Faster than what?

>> Even if this works for you (i.e. you use --link), it still requires two
>> stats per file, so it's still slower than the inode-sig check below.
>> Sounds like a pessimization to me.
> We had to do the stats anyway, to make sure that the file type and
> permissions haven't changed.  That code reuses the lstat results that are
> already necessary, so it's zero-cost.

I don't understand what you're talking about.
We need:
- one stat per work-tree file.
- compare this result with a known value (which can come from the
  work-tree's inode-sigs or from the rev-lib).

Getting the known value from the worktree's inode-sigs can be done without
any stat (just one big read and then in-memory searches).  I do see that
doing stats in the revlib will not be much slower if things are hardlinked
because the work-tree stats already brought the inodes in the cache, but
I can't see any reason why it would be faster than using the worktree's
inode-sigs.

>> Also the work-tree inode-sigs need to be updated more often than just
>> during `commit' so they're more effective..

> I don't see the need here.  Are you frequently modifying and undoing large
> numbers of files?  Because for the 3-files-have-been-reverted case, it's
> just not worth it.

No, but I have several trees where I mostly never do `commit': I mostly do
star-merge, or things like that.  By now almost all files where modified by
star-merge, so their inode-sigs don't match even though `tla changes'
only lists three modified files.

> Perhaps what we need is a gen-inode-sigs command, so the user can assert
> that the revlib is okay.  (presumably after an md5sum check or something)

Yes, that would help.  I have already been several times in the situation
where tla refuses to use a revlib even though I'm pretty sure it's
not corrupted (but its device-number has changed, or it has been copied
from one drive to another).


        Stefan