On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull<step...@xemacs.org> wrote: > I'll have to try them again now that 1.3 is out, but I found Mercurial > named branches fundamentally unsuited to release management.
Can you explain why, please? It's not clear from what you say below. > Ditto named branches. The problem is that (unless the internal > implementation has changed very recently) a Mercurial revision can be > on exactly one named branch (or on the trunk). That's still true. > Which defeats the purpose of having named branches, really. (I mean > the version control purpose; obviously it still can save disk space.) Why does it defeat the purpose? What, in your opinion, is the purpose? > Unless you're really short on space, though, that's not a big deal. > What would be more important to me (not that I matter for the purpose > of Python, but in XEmacs -- also a Mercurial shop -- I do :-) would be > the other way around: pulling an external branch into a named branch. > I have a feeling that working with such a repository with others would > be a little difficult. Can you give an example? > Stick with the CPython notation. At XEmacs, continuity of tags has > made our beta testers happy. (Well, the two of them who bothered to > mention it, anyway. :-) Right; Benjamin also mentioned that processing the tags just to be consistent with the recent tagging scheme would probably be the best solution. > As others (MvL, I think) have commented, this isn't really relevant to > Python which generally has four mainlines going at once. I don't see > why the requirements are going to change with the shift to hg, and I > see no reason why hg won't handle the existing workflow just fine. It will handle it, for sure, but I think it would all go easier if we could work with stricter subset branches (and leave the effective cherrypicking for the occasional problem). Cheers, Dirkjan _______________________________________________ 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
