Re: [Gnu-arch-users] [BUG] [FEATURE-REQUEST] Caching mechanisme for patch-logs

[James Blackwell]

Matthieu Moy wrote:
> For most tla operations displaying lists of revisions, using the
> options --summary, --author, --date make tla very slow because tla has
> to fetch the log file for each revision displayed, and this log file
> is often on a remote server.
>
> I suggest a caching mechanisme for patch-log entries, like we already
> have revision libraries to cache working directories. My proposal is
> to implement this as an extension of the revision library mechanism,
> but we could also imagine a separate library.
> There would be a command
>
> $ tla library-add --log $revision

I just poked around in one of my libraries, and it looks like we already
have patchlogs stored in the libary.

However, it looks like revisions, abrowse and rbrowse don't know how to
use libraries.


> To add the log file to the library. As a possible optimisation, the
> file can be a hardlink to the corresponding patch-log entry in the
> revision library. (In this case no need for a network access)

Ahhh, you seem to already be aware of this.

I think we can get 90% of the benefit with 10% of the work by teaching
those three or four commands to try and pull logs from the libraries
first. That should be easily doable by teaching t_uchar *
arch_archive_log(struct arch_archive *, t_uchar *) how to use
libraries.

If we did this, then we're also adding some sort of
{archives}-libs/=greedy-patchlogs option, which would add the full
missing revision (patchlogs, changeset and all) to the library.

I can only imagine how much this would thrill Miles; rbrowse would
certainly zip along then!


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400