Re: [Gnu-arch-users] problem with ,,inode-sigs optimization

[Tom Lord]

    > From: Miles Bader <address@hidden>
    
    [re: inode signature optimizations]

    > ... it seems to stop working after you use `replay' or `update',
    > presumably because the current latest revision no longer has an entry
    > in ,,inode-sigs (even though almost nothing will have changed).

Oops.  Yup, I'll fix that.  It's a few days work, though.  Wouldn't
hurt to file it as a bug if you haven't already.


    > From: Miles Bader <address@hidden>

    > I wrote:
    > > Some idea for solving it --

    > >  (1) Have replay/update/whatever update ,,inode-sigs;

    > >  (2) Don't keep per-revision state at all, just keep single per-version
    > >      state-file in ,,inode-sigs.

    > Oh, wait, I was confused.  (2) doesn't make any sense [....]
    > so I guess it's gotta be (1)...

Heh.  Yes, it has to be (1).  If you want some fun, try to imagine how
you do that for `replay', though.  Don't forget that there may be
local changes already when the `replay' starts.

Update's not nearly so bad if you don't mind tossing in an extra
tree-traversal just before local changes are reapplied to the tree --
the tree is known to be equal to a particular revision at that point.

Hint: no, you can't keep around "stale" entries from the ancestor
revision's ,,inode-sig file.  A user might revert some changes in a
manner that makes the stale entry into an invalid entry that will fool
`commit'.



    > Bloat's still an issue though, so it seems as if it should be pruning
    > these things after a while, perhaps in conjunction with the associated
    > pristine tree.

They are already pruned, in a simple-minded way.   Only the five most
recent ,,inode-sigs files are kept for each tree.

-t