gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Registered and official names


From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Registered and official names
Date: Fri, 30 Apr 2004 11:29:10 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

James Blackwell wrote:
In lists.arch.users, you wrote:


What about using registered names for the read side? Currently, "tla tag foo-MIRROR/version foo/version" succeeds, but will do the wrong thing, writing the registered name to the CONTINUATION file and logs. Also, it erronously caches a revision.


I think you're right; there's enough challenged people out there that
this particular corner should be padded. I suggest the following:
if (provided_archive !=  `=meta-info/name`)
  {
    require --im-smarter-than-you flag;
  }

That's one way of handling it, and considering how rarely we want to access -SOURCE or -MIRROR archives, it might be worth putting the check in arch_archive_connect().

On the other hand, it's certainly feasible to make tagging (or getting from) a registered name work properly.

However, if we had read caching, we wouldn't need local mirrors. That would reduce the need to write to registered names, and we could just mandate the use of official names everywhere (except archive-mirror).


With mirroring, I have a guarantee that, at the time of mirroring, I
have everything that is in the archive that I'm mirroring.
Would read caching make the same guarantees?  I'd hate to mirror an
archive, head off to the park, and find out I'm missing something from
that archive.

That's not a use case for me, and I most certainly don't want my cache to be a mirror. I want the cache to prevent me from downloading something twice, but I don't want to download anything I might not need.

That said, the implementation would probably be a mirror variant, so it probably wouldn't be too hard to make archive-mirror work with caches.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.




reply via email to

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