Re: [Gnu-arch-users] Fast commits

[Tom Lord]

    > From: Harald Meland <address@hidden>

    >>> If you know where to _find_ the ++version-lock directory then you
    >>> already know what `last-revision' would say.

    >> I know where to find it based on the <p>--<b>--<v> tuple, no need for
    >> the patch level. But in fact, what looks like being time consuming
    >> when committing from a working tree containing a patch log of about
    >> 10'000 logs is the traversal of the patch log directory in the working
    >> tree.

    > I'm not at all sure that I fully grasp this stuff -- but for local
    > files, could it be that some kind of stat()-using binary search for
    > the latest revision is faster than a full readdir()-based traversal?

No.  One point is that there's no need for a file called
`last-revsion' in the ++version-lock directory because that directory
is normally stored in a directory named `patch-N' where that's the
same string that would go in the `last-revision' file.  By the time
you can open the `last-revision' file, you don't have to.

The other point was that there is no need to search at all for the
++version-lock directory unless you are using the --out-of-date-ok
option to `commit'.  No need to binary search with stat.  No need to
readdir.   Tla currently happens to readdir anyway -- that being just
one convenient way to do it.   Somebody noticed if that directory
listing contains 10,000 files and you're readdir-ing over a
low-bandwidth net connection, that this could be slower than one would
like --- so, someday (and abentley apparently has patches for this
already) that readdir should be removed.

The full traversal of the patch log is something entirely different
and is unavoidable -- the same reason it's unavoidable to traverse the
source tree during a commit:  to find out the inventory of the tree.


-t