| 1. We tag all the repos after a successful bootstrap on each platform.
| Main problem with this: profusion of tags, obscuring 'darcs changes'
| and 'darcs query tags'. Space itself isn't really an issue; a tag
| only adds a few hundred bytes.
|
| We could mitigate the effect by rate-limiting the tags, say only tag if
| there hasn't been a tag in the last week. Then we'd get one
| guaranteed-buildable state per week or so, which seems reasonable.
|
| 2. We keep a separate set of repos that are only updated after a successful
| build. Perhaps one set of repos per platform.
| Main problem with this: ensuring atomicity during the update (probably
| not likely to be a significant problem in practice).
| Second problem: this doesn't store the repo state of every successful
| build, only the most recent one.
|
| Personally I lean towards (2), as it's much easier to implement. Any further
| comments?
(2) seems good to me. Furthermore, if we published
Last good build is at repo http://darcs.haskell.org/ghc-2007-02-09
(so the date is in the repo name), and refrain from publishing until the repo
is really there, there'd be no atomicity issues would there?
(We can just delete older ones after a bit.)
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
