[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Making archives and rbrowse self-documenting
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] Making archives and rbrowse self-documenting |
Date: |
Tue, 13 Jan 2004 09:37:47 -0800 (PST) |
> From: James Blackwell <address@hidden>
> > $ tla archives --verbose
> > Andrew Suffield's Debian-related packages
> > address@hidden
> > http://people.debian.org/~asuffield/archives/gluck-2004/
Once upon a time, or maybe twice ... I forget
Archives, each category, each branch, and each version could contain
an optional =README file. The idea was quite similar: that was a
place to store a description of the archive's contents.
Two problems arose:
1) People generally didn't use them.
That was then (when there were fewer archives floating around)
and this is now. Perhaps this problem would fade away.
2) They cost a lot during push-mirror.
Unlike the revision data files =README files aren't "write once".
In theory, mirroring operations would have to check them for
up-to-dateness. Mirroring operations _did_ check them for
uptodateness, that proved stupidly expensive, so the feature was
removed.
I think I saw some chatter go by on #arch the other day about the
topic of whether or not descriptions in mirrors should always be the
same as in their sources -- so I guess that that's a third problem.
The big issue being push-mirror speed, that raises the idea of using
rsync tools instead or of using complex timestamping mechanisms to
optimize push-mirror. The former ("use rsync") isn't a bad idea but
I'd like to not introduce a dependency on anything other than dumb-fs
transports so it doesn't count as a solution. The latter is unlikely
to work out cleanly and robustly (what if I just edit the =README file
directly, for example?)
So I'm inclined to play the "design principle" trump card here:
arch does its job by providing this namespace of revisions. The
descriptions aren't needed for that. While the descriptions may be
useful -- they are an add on. Some "other tool" should manage
them, using the arch namespace as a database key.
I'd have no problem reserving some file namespace in archives for
add-on tools like this -- just so long as arch itself simply ignores
those files.
-t