Moving PyMOTW to a public repository

Originally posted · 5 min read

I’m investigating options for hosted version control tools to managed the PyMOTW sources. Currently the files are in a private svn repository, but that makes collaboration difficult. This also gives me an excuse to look at DVCS tools to see how they compare.

Contenders

There are 4 contenders, listed here in no particular order:

  • Google Code (svn)
  • Bitbucket (mercurial)
  • Launchpad (bazaar)
  • GitHub (git)

I’m not all that keen on git, mostly because my impression is that it is hard to use. I have no direct experience, so obviously that has to be taken with at least a grain of salt. I’m familiar with svn, have a good tool chain built around it, and use it on my other projects, including Google Code. I don’t have a good sense for the barrier to entry for other users, though. Do people still choose to start projects on svn, or is everyone moving to the newer DVCS-based repositories?

The two other DVCS options seem to have mostly similar feature sets, although I’m still reading about them so maybe I haven’t hit the differentiating features, yet. I know that the Sphinx project uses Bitbucket and I’ve been told the Python core developers may be looking at bzr (but probably not Launchpad).

Google Code

I use Google Code for some other projects, and we use svn at work. I’m using that experience as a base-line for evaluating the other options.

Bitbucket / Mercurial

I was able to install Mercurial with a simple:

$ easy_install Mercurial

I found instructions for enabling the “convert” plugin so I could import my svn repository. My first attempt failed because hg couldn’t find the python bindings for svn. @cyberdrow helped me out via Twitter, and after setting my PYTHONPATH=”/opt/subversion/lib/svn-python” I was all set.

The conversion took a little while to run, but eventually I had a local Mercurial repository with all of the trunk changes. I wanted the “releases” tree to be used for tags, but I guess that’s not a standard naming convention so the tool ignored that part of the tree. No matter, I can work out where to set the tags myself or investigate other options later.

Bitbucket seems like a fairly streamlined code hosting solution. In addition to Mercurial hosting, there’s a wiki and an issue tracker.

Private repositories

It looks like I’ll only have the ability to create a single repository under the free plan, though, so I’ll have to consider whether I want to get into the paid hosting plans for other projects. At $5/month, I’d be able justify subscribing for several years before I matched the cost of the effort it would take for me to set up a secure server with the same features myself.

Launchpad / Bazaar

Importing into Bazaar was a little more confusing, ironically because of the transparent way they have implemented it. The bzr-svn plugin lets you “branch” directly from a subversion repository to create a local copy managed by bzr. Apparently changes can then be pushed back to the original svn repository, although that’s not what I intend to do.

The version of bzr I got when I ran easy_install didn’t include the bzr-svn plugin, but after deleting that copy and downloading the OS X installer from the web site I was able to run:

$ bzr branch svn+ssh://server/path/to/svn/repository PyMOTW-bzr

to create a local bzr repository complete with all of the change history. This time it did import the release history so I had “trunk” and “releases” directories in the local copy. Including the “trunk” directory in the branch URL gave me something more closely matching the results from “hg convert”.

Launchpad seems to have more features than Bitbucket. One nice feature for code projects is “Blueprints”, which can be used to discuss designs and plans before beginning implementation. There doesn’t seem to be a general-purpose wiki, but PyMOTW doesn’t really need much of one anyway.

The Launchpad UI feels a little less obvious to me. Perhaps that has to do with the fact that most of the views show combined data for all projects, not just my own. That’s an interesting approach for open source in general, but not necessarily applicable for this project.

More Research Needed

That’s all the research I’ve had time to do, so far. I’ll be looking at git and GitHub soon because I’d like to try all of the various options before making a decision.

In addition to the basic commands, I need to make sure I understand how to formally branch with each tool. I tend to work on the article for a module by creating a new branch, then merging back into the trunk when I’m done. I’m paranoid about backing up work-in-progress, so I really want a way to commit to a branch hosted somewhere other than my laptop. In svn, I use the usual “svn copy” commands to create a new working tree within the repository. Mercurial has a notion of branches, but it works differently (perhaps more like the old CVS branches?) so I need to study it more. Bazaar seems to create an entire copy of the repository when a branch is made, rather than storing the branch in a way that lets me save copies of data in the central location. It isn’t clear yet if I can do something to create the branch on the shared repository.