On Jun 7, 2008, at 5:52 PM, Ali Saidi wrote: > > On Jun 7, 2008, at 5:44 PM, nathan binkert wrote: > >>> Aren't these statements contradictory? If you have the patch sets >>> under separate subdirs, can they come from different repos? Would >>> you >>> still have to manually merge the series file? I don't totally blame >>> Gabe for having the willies about this. >> Yeah, it sorta gives me the willies too. Maybe what I suggest below >> could be better. > They aren't. Merging patches in an ugly business that I think we > should avoid. MQ is pretty flexible about patches and subdirectoires > so you can have various directories under .hg/patches each of which is > a hg repository, however hg qcommit and the like won't work. Yes you > would have to manually update the series file with all the patches > from each directory. In reality if we went down this path --- which > I'm not endorsing at all --- I would be tempted to hack MQ so that > the root series file could just be pointers to other series files. > >> >> >>> My main fear is that if all we offer as a default download is the >>> tip, >>> then if something broken gets in there and someone downloads m5 for >>> the first time and it doesn't work, that's not good. Maybe Nate's >>> idea of automatically advancing the stable pointer once we've run >>> the >>> fullest possible set of regressions is the right way to go, and we >>> can >>> try harder to make sure that when we see some configuration break we >>> create a regression test for it. >> I think this, combined with something like a testing repository which >> has regular regressions run as well and is maybe similar to the >> mercurial crew repository. Basically, people are allowed to push >> more >> speculative things to the testing repository, and they'll get >> regressions run on that repository. (If we do some sort of automatic >> bisect, that would be awesome) If the testing repository gets >> totally >> whacked, it's easy to blow it away and just ask people to re-add >> stuff. Maybe this should be done with a mq repository instead of a >> normal repository. (Is this what you had in mind steve?) This way, >> when people commit stuff, they can remove it from the queue and not >> figure out how to merge it. We could also alternatively come up with >> some way to just have a directory of mq trees that can be >> individually >> maintained by people, and have the regression framework automatically >> do a separate regression on all of the mq trees that are there. > I just look a quick look at the hg webserver code. There isn't a > direct way to download a revision. We could add one, or we could go > back to my original suggestion that we have m5-stable and m5-dev and > just pull to m5-stable at whatever interval. I even wrote a script to > spam m5-dev if more than XXX days had gone by without an update to m5- > stable. Just like Nate says we can then whack m5-dev if something goes > awry and reclone from m5-stable. Another reason to have separate repos instead of just tagging if we're going to do stuff at this rate is that each retagging generates a new changeset. Pulling from a repo named x to a repo named y doesn't.
Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
