Re: [Gnu-arch-users] archive-mirror not pushing cacherevs?

[Johannes Berg]

On Sun, 2004-01-11 at 22:12, Johannes Berg wrote:
> [stuff that sparked quite a discussion]

Having thought about this again, I do agree that going back in time is
bad, and mustn't be done. However, doing a cacherev doesn't really
mean going back in time, its more like giving others a combined view
of the history for some historic point. Therefore, I might even be
inclined to argue that the cacherev files shouldn't even be in the
normal directories.
That however, would be stupid, because it would simply duplicate
structure, as James pointed out.

As more argument for the issue, consider the case where I provide a
branched version of some project. Now the original archive goes away.
Then I'll simply cacherev my base-0 tag, and everyone is happy because
they can get that code (presuming of course I still have it in a local
mirror or my revision library, otherwise we're screwed and I can only
cacherev the earliest revision that I have).
If, otoh, I would be forced to cacherev my current patch-n, then nobody
would be able to go back to my patch-m (m<n) without weird tricks like
reverse-merging (which should be possible, I think).

So, considering the case that cacherevs should be allowed for historic
versions, here are the attempts at solving them that I've seen so far:

Miles:
  * create a dir that contains an (empty?) file for each cacherev,
    enumerate that dir in archive-mirror
  * append to a file which is re-read by archive-mirror

James:
  * add a header to log messages:
    Revision: test--jmb--0--patch-57
    New-cacherevs: test--jmb--0--base-0
      test--jmb--0--patch-32
    Removed-cacherevs: test--jmb--0--patch-25
    [...]
    which would simply annotate the existance of cacherevs.
  (heavily interpreted from what you wrote, James, correct any mistakes)


Based on that, here's a new proposal. Mostly some things that came to my
mind, if no one bothers to read it I won't be disappointed, I guess its
not really organized.

Since there has been talk about having some versioned meta-data in the
archive anyway, why not go ahead and implement/use add that?
I propose to add a category 'archive-meta-data' to the archive.

Within that, it is easy to define branches, for example a
archive-meta-data--cacherev branch. Any cacherev/uncacherev would
commit to that branch (don't ask me about a version number), with above
log syntax I invented to illustrate how I understood James' suggestion.
The changeset would then always be empty, that somewhat bothers me
because it is a waste of space, but its not much (a 4k block).

Another branch in the archive-meta-data category could be descriptions
(archive, category, branch, version). 
Ideally (really?), you wouldn't be allowed to check out that category
(or really? not sure if that's any good), and have some special
commands.
        tla cat-readme [archive/][category[--branch[--version]]]
        tla get-readme [archive/][category[--branch[--version]]]
and a readme is just a message like:
--
Readme-For: archive/category--branch--version (whatever it is for)
Summary: short explanation

detailed explanation
--

and
        tla put-readme [archive/][category[--branch[--version]]] file
which pushes that to the =archive-meta-data--descriptions branch, and
then of course
        tla create-readme [archive/][category[--branch[--version]]] [file]
which just creates a simple readme like the one above where the header
is correct, but all else is empty. Refuse committing an empty Summary
etc.

Maybe a tla get-readme could also automatically add/change a
Last-Modified-Date: header, which is simply the last log entry date
relating to that readme.
Within the readme-branch, readme's can be organized in directories just
like the archive is organized. The Modified-files header of the log can
easily be used to discover which changesets are relevant to a certain
readme file. There could also be logic to always carry a cacherev along
this branch whenever it is updated. It should be very small anyway.
[...]

I'm sure others can come up with many other nice uses.

Now here are some disadvantages:
  * cacherev needs to sign two things for a signed archive
  * users can check out the special category and mess with it

and advantages:
  * backward and forward compatible, meaning that now-current versions
    of tla will ignore the special category name fully,
    and new things can be defined in new branches, thus having
    no problem with versions of tla that only know how to interpret
    some branches there.

johannes
-- 
http://www.sipsolutions.de/
GnuPG key: http://www.sipsolutions.de/keys/JohannesBerg.asc
  Key-ID: 9AB78CA5 Johannes Berg <address@hidden>
  Fingerprint = AD02 0176 4E29 C137 1DF6 08D2 FC44 CF86 9AB7 8CA5

signature.asc
Description: This is a digitally signed message part