Just to help settle this, I will write something and work with the appropriate people to get something worked out. I will most likely branch the devguide with an hg_transition branch and work in there so people can still publicly participate but not have it affect the published site.
On Sat, Feb 5, 2011 at 10:08, R. David Murray <rdmur...@bitdance.com> wrote: > On Sat, 05 Feb 2011 02:07:52 +0100, <mar...@v.loewis.de> wrote: >> > Indeed. Mainline is the only branch where we *know* most patches need >> > to be applied. It also means that people can contribute while >> > maintaining only a single checkout, rather than necessarily needing >> > all active versions. >> >> Notice that you'll automatically will have all active versions >> available, if PEP 385 is implemented. A single clone will have all >> maintenance branches as named branches inside, so integrating >> a bug fix should be a sequence like >> >> hg update release32-maint >> patch >> hg commit >> hg update default >> hg merge release32-maint >> hg commit -m merged >> hg push >> >> Sprinkle test runs into this to your taste. > > What about compiles? And perhaps even make distclean/configure? With our > current workflow I have separate checkouts for 2.7, 3.1, and 3.2, and > run make when I see a c file go by after an svn up (and make distclean if > I see an update to a .in file, though I know that isn't always necessary). > > Is there a way to translate that bit of the workflow to hg, or do I need > to run make after each update, and make distclean if things fail to work > as expected? Will running make after an update always do the right thing > (ignoring those issues for which make distclean is currently needed)? > > We really really really need some to document the expected best practices. > Even if there isn't agreement among the hg veterans yet, someone should > document *something* that we can iterate on to reach a preliminary > consensus so us newbies have something to work from when the switchover > is made. > > I'm with Nick here; I don't have a project that uses hg, and until I do > no amount of reading about it is going to do any good. And even after > I'm going to need help...I tried using bzr for email6 and I *still* > don't understand how to use it properly. Of course, nobody had written > a best practices guide for me for my project, which is why I'm joining > the chorus asking for one for Python :) > > -- > R. David Murray www.bitdance.com > _______________________________________________ > python-committers mailing list > python-committers@python.org > http://mail.python.org/mailman/listinfo/python-committers > _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
