[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: libraries don't play well with partial mirrors

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Re: libraries don't play well with partial mirrors
Date: Fri, 07 May 2004 16:24:06 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

Jason McCarty wrote:
Aaron Bentley wrote:

That's another argument for local caches instead of local mirrors;

Maybe, but in this case I would want most of the changesets to be
locally cached, as well as a few full revisions. Sounds a lot like a
partial mirror+revlib to me.

No, cache+revlib would be much better.

The differences between a mirror and a cache are
1. if data is not in a cache, that's a cache miss, not a corrupt mirror.
2. a well-designed cache will never return outdated data
3. partial mirrors contain entire versions, while caches can contain parts of specific revisions 4. caches can be used in such a way that they will not download unnecessary data

The differences between a cache and a greedy are
1. archive-format storage takes much less space per revision
2. archive-format storage cannot be used as a reference tree
3. caches often have a fixed maximum size

Well, if you have a library revision for tla--devo--1.2--patch-114, you can't determine whether that's an ancestor of tla--devo--1.3--patch-2 without consulting the revision data for all intermediate revisions.

But if my mirror doesn't contain the 1.2 branch, I don't expect my
revlib to either.

Why not? Maybe that's true for your case, but it's not necessarily true in every case. I can well imagine that I might mirror Tom's archive, but I still have revlibs for 1.2.

It would sure help the backbuilder if stuff like this didn't cause immediate program termination. The backbuilder doesn't need every arch_archive_connect to succeed, but arch_archive_connect will panic if it fails.

Sounds reasonable. Is my bug one of those failures which are easily

With the current code, it could be done by checking for missing revisions before determining their type. This would cause the archive scan to take twice as long. Or else we could change the interface of arch_revision_type() so it can indicate a missing revision.

Any fixes to the current code will be obsolete when the backbuilder's integrated. It currently doesn't tolerate missing revisions.


Aaron Bentley
Director of Technology
Panometrics, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]