Petr Baudis [off-list ref] writes:
By the way, this is only a pathetic remnant of my brave effort to get
rid of seeing the "Getting alternates list" message on the same
repository 20 times now since the parallel fetching got introduced.
I know how to do silence the messages, but doing the _fetching_ itself
seems as downright stupid thing in the first place.
Therefore, can I somehow stall fetching of an object? The idea is:
I want to check the alternates list!
I don't have it yet...
...but a request for it is already queued. Ok, I'll wait.
I agree, and probably this applies when index request is in
transit as well.
On Fri, Nov 11, 2005 at 05:17:42PM -0800, Junio C Hamano wrote:
quoted
Therefore, can I somehow stall fetching of an object? The idea is:
I want to check the alternates list!
I don't have it yet...
...but a request for it is already queued. Ok, I'll wait.
I agree, and probably this applies when index request is in
transit as well.
I just posted a patch to prevent another alternate request from starting
if one is already in progress.
This should not be an issue with index requests because they are only
initiated from fetch(). The previous patch to load alternates on demand
added alternate handling to process_curl_messages() so that a 404 for an
object can be handled immediately rather than waiting for the fetch()
call for that object to notice.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
On Sat, Nov 12, 2005 at 09:22:02AM -0800, Nick Hengeveld wrote:
This should not be an issue with index requests because they are only
initiated from fetch(). The previous patch to load alternates on demand
added alternate handling to process_curl_messages() so that a 404 for an
object can be handled immediately rather than waiting for the fetch()
call for that object to notice.
Seems like it might make sense to handle pack downloads immediately when
an object is unavailable rather than waiting for the fetch() call. It
could prevent attempts to download any other objects inside that pack,
although queued requests that activate while a pack is downloading
would have to wait to see whether the download is successful. If such
an object also exists loose it would prevent a redundant download and if
not it would at least prevent an unnecessary check and 404.
Thoughts?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.