I started the branch, so any commits to the devguide mentiong hg, you can rest assured they are not going to the live site. =)
I will get a workflow written up and then email the people I know who are already heavy hg users (Antoine, Georg, and Dirkjan; if you want to be included in the discussion let me know) to read it over. Once we have agreed that the docs as written are accurate and we think they are best practices for what we want, I will let python-committers know and people can have a look to make sure everything is clear and easy to understand for when the transition occurs. This will also give Nick a chance to make sure the dev FAQ is ready to go since he wanted it kept alive. =) On Sat, Feb 5, 2011 at 11:44, Brett Cannon <br...@python.org> wrote: > 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
