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
