Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote: > On 2006-08-22T06:36:57, Alan Robertson <[EMAIL PROTECTED]> wrote: > > Uhm, I don't mean to jump in, but: > >> > This requires Hg, a shell account (for the updates) and a webserver >> > (to make them available). Details on configuring the webserver can be >> > found at: >> > http://www.selenic.com/mercurial/wiki/index.cgi/PublishingRepositories >> > I chose the hgwebdir option. >> > >> > If you want us to push to a "master" repository, then you need to >> > follow these links: >> > http://www.selenic.com/mercurial/wiki/index.cgi/SharedSSH >> > http://www.selenic.com/mercurial/wiki/index.cgi/HgWebDirStepByStep >> > and decide which method suits you best. >> > >> > Until any or all of this is set up, people can use Hg locally and either: >> > a) wait for a central location to become available >> > b) set up their own host to publish their repositories >> > c) use "hg bundle" to send me updates to be applied to the heartbeat >> > repository on hg.beekhof.net >> > >> > I'd really prefer people didnt commit to CVS because re-massaging the >> > data and verifying the tags is a major PITA. >> >> >> Sorry. >> >> It's WAY too late for that. >> >> Until we have a master repository, we'll continue using CVS - we have no >> choice. > > So, ignoring Andrew's point about him not wishing to continue to use CVS > (which is, I'm afraid to say, of course unworkable until everyone has > switched to hg, and we need to set a date for that - I take it that > Andrew simply wishes to speed that process along, instead of seeing it > being ignored), might it be inferred from your posting that you indeed > wish to setup a central repository where we can push to? > > (Which, I think, is also a question raised by him a number of days ago > in a private thread between you, him and myself where he asked for your > input ...) > > It'd be great if you could briefly elaborate the reasons for that, as it > appears LKML for example seems to prefer the pull model, with the > centralized control currently being held by Linus. > > If so, I'd suggest to do just that. I'm sure Andrew will be glad to be > of help with that part of the operation. > > I'm gladly out of the loop, being on vacation this week. I trust you'll > all be happy to make progress without me ;-)
I'm pretty cofortable with the pull method as we see used on the Linux kernel. But it does really require someone to be doing the pulls, and least keeping track of what changes are being pulled in and from who. The actual merge process should maily involve hg doing work rather than whoever is operating the tool. I'm also fine with using a push based system. Though I think this misses out on the kind of quality control that someone (or a hierachy of someones) imparts. Push does however seem to be a path of less resistance as its very close if not the same as the way we have worked with CVS in the past. As for a switch-over date. Its really no different to a tree freeze, which we have done many times in the past, sometimes at very short notice. We just stop making commits, make sure everything is is in good shape, then start making them again. The only difference is we use a different tool. At this time, persumably CVS has not diverged very far from the painstaking work Andrew did to import everything to hg. With this in mind, I propose going into a "freeze" now. I for one do not intend to make any more commits to CVS. My trees are, for now, on http://hg.beekhof.net/ . So I will be one less source of noise in CVS. (Although the only I have added to hg so far were previously added to CVS). -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
