On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull<stephen at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4