Re: [Gnu-arch-users] Fast commits

[Harald Meland]

[Robin Farine]

> Tom Lord wrote:
>
>>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 thought that knowing the patch number would help, but now I realize
> that the computation of the change set includes this traversal and a
> similar traversal in the reference revision. So yes, the only
> reasonable solution in such a situation is to have more versions and
> to prune logs like hell.

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?

I.e. start by stat(version-0); if found, do a binary search on the
versionfix-N part of Arch's revision name namespace, otherwise
stat(base-0) and do a binary search on the patch-N part.  If I
remember my big-Ohs correctly, this would make the lookup O(log N).

Using stat() instead of readdir would probably be slower on versions
with few revisions -- but maybe not significantly so.


If implemented, I'm not sure that this would satisfy Tom's "apparent
usefulness" vs "added bloat" standards.  Also consider that when doing
similar lookups over a potentially high-latency network, a order-once
ls(1)-like interface would probably beat a
ask-if-revision-exists-and-wait-for-answer stat() solution hands-down.
-- 
Harald