[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Getting revisions w/ HTTP protocol and time to complete
From: |
Edouard Gomez |
Subject: |
[Gnu-arch-users] Getting revisions w/ HTTP protocol and time to complete |
Date: |
Thu, 16 Oct 2003 22:28:57 +0200 |
User-agent: |
Mutt/1.5.4i |
Hello,
I know there was a discussion about intermediate patche-(N)-(N+M)
patches to speed up the "tla get" command w/ distant archives.
As i don't remember all the details, and i don't find the thread in the
archive (this last month is only one big thread covering lot of
topics... :-( ) I would like having some news about this topic.
In my case, having intermediate pacthes would not really be worth it,
because patches are really small, and thus getting the patch/applying
the patch is not a costful operation. I get this for only 70 revisions:
$ time tla get address@hidden/xvidcore--devapi4--1.0
real 1m9.004s
user 0m5.632s
sys 0m3.024s
On this 1m9s total, ~30s are spent going through every revision dir to
find a cached rev.
In order to compare, getting it from CVS, i get:
$ time cvs -z9 -d:pserver:address@hidden:/xvid co -r dev-api-4 xvidcore
real 0m9.824s
user 0m0.204s
sys 0m0.141s
So as a first step, for speeding up the get command, is there somewhere
(an archive :-) with an implementation of a kind of "super" .listing
file that lists recursively all the contents of revision dirs for all
category versions. This way the cached rev searching could be replaced
by a simple file retrieval + string search.
This "super" index would not fill the gap between tla and cvs, but it
would make tla feel much responsive as it would find the cached rev
faster, thus beginning what the user preceives as the "real" get
command, ie get patch levels and apply them.
--
Edouard Gomez
- [Gnu-arch-users] Getting revisions w/ HTTP protocol and time to complete,
Edouard Gomez <=