[Python-Dev] Subversion branch merging

[Dave Harrison]

Brett Cannon wrote:
> On 7/12/07, "Martin v. Löwis" <martin at v.loewis.de> 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