2009/7/4 Brett Cannon <br...@python.org>: >> > While I really like the idea of using named branches for each release so >> > that there is a single py3k branch that contains all relevant history >> > for >> > every release, I think we should start simple and go with cloned >> > branches. >> > That way the workflow does not radically shift from what we do now for >> > svn >> > to start. Once the conversion is done and people are comfortable with hg >> > we >> > can then discuss moving towards a named branch approach. >> >> I don't think the cloned branches is much simpler than the named >> branches approach, in several ways. For example, populating the branch >> part of a sys.whatever value is significantly harder. Also, if you >> follow a useful tagging approach, doing cloned branches means that >> release tags aren't available on trunk/main/default. That seems like a >> step backwards. > > I personally prefer named branches, but that's just me and I am not about to > force my preferences on everyone. Guess we just have to see if others have > opinions against named branches.
Personally, I prefer clones, as it seems to me that Mercurial named branches are not quite what people generally think of when they think of "branches", in some subtle respects. I could be wrong, as I don't personally use named branches. However, there's been a small thread on distutils-sig recently with a new Mercurial user complaining that he's got confused and messed up a repository. Without digging particularly deeply, it appears that the problems were caused by confusion over named branches. FWIW, the Mercurial book (http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html) describes named branches with the comment "If you're more in the “power user” category (*and* your collaborators are too)" (author's emphasis). I'm not sure we want to require contributors to be "power users" of Mercurial... Paul. PS Sorry for responding to an old thread - I couldn't locate more recent discussion, although I thought there had been some. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
