Stefan O'Rear wrote:
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).
We talked about this idea a little on IRC, unfortunately it has two pretty
serious drawbacks:
- if the user's local repo has some recorded patches that aren't in
the main GHC repo, they'll get unpulled too. Getting a tree from
scratch is fine, but this method can't be used to update a development
branch to the latest working HEAD, which was one of the goals.
- the tags may appear in the context of patches that people 'darcs send',
which would force us to pull the tags into the main repo (or tell
people not to do that, but we don't want to add extra obstacles for
contributors).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
