On Fri, Jun 01, 2007 at 05:09:23PM +0100, Simon Peyton-Jones wrote: > | 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.)
3 (mentioned earlier): Like 1, but don't push the tags. Instead we darcs send -o them and publish. The workflow for a checkout is: darcs get /my/local/fullghc/repo /ghc/build/path cd /ghc/build/path wget http://url/of/latest-tag darcs apply latest-tag darcs unpull --from-tag=BUILDS This has the space/network usage of (1) and the infrastructure ease of (2). Stefan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
