Brett Cannon wrote: > On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> I'm tasked with performing a number of merge operations across >> various Python branches. Can somebody please share a command >> line that I should use to continue with the merge tracking that >> has been used? Is that documented somewhere? > > You mean using svnmerge? If so, see the dev FAQ: > http://www.python.org/dev/faq/#how-do-i-merge-branches . If you are > after something else then I don't know. =) > > I do know, though, that Thomas kept talking about moving us over to > Bazaar (or some distributed VCS) and instead of having a ton of svn > branches we have distributed VCS branch for each feature in Py3K. > That way the VCS's strong merge system would work in our favour for > pulling in from the various Py3K branches and for eventual mainline > merging. > > -Brett
Hi all, While I'm generally just a silent listener to this list, I thought I'd share my experiences with distributed SCM - primarily because I think it's a great step in the right direction. So far I've used DARCS, Hg, and Git. And at this point Git is far and away the winner. While I can't claim to have spent alot of time with DARCS, my experience was that it took a fair whack of unintuitive pain to work out how to extract a patch that I could send upstream to be submitted to a project. I believe it also has a reputation for being rather slow. I've also noticed that repositories sometimes become "broken" and need to be re-checked out - but that I'm willing to put down to some other factor I'm not aware of. With Hg I went in fast and hard, and nearly got burned before I could bail out in time :-) It's very friendly to use, but we run a number of OpenBSD hosts for our core architecture, and it turns out Hg wraps calls to patch, and parses the text output from the call (assuming the version of patch is GnuPatch). The problem here is that under OpenBSD the output assumptions get violated, as reflected by the failure of lots of tests - including repository sanity checks. That meant Hg just wasn't going to be an option for us. I also found that having a new directory tree of files for each branch was rather onerous. Having bailed on Hg I found git to be fast, cross platform, and user-friendly (provided you understand the basic concepts of distributed SCM, and you're using git 1.5+ ;-) ). It also has some really cool features like "rebasing" for letting your branch actively track the trunk from which you branched it. I can't speak to how easily any of these cross over to the windows platform, although none of them seem to be overly windows friendly (YMMV). But I presume this would be one of the key problems facing a distributed versioning system by the python community. Cheers Dave _______________________________________________ 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