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

[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





reply via email to

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