converting virtualenvwrapper repository to git

If you have forked virtualenvwrapper, you’ll want to update your fork to
use the new git repository at
https://bitbucket.org/dhellmann/virtualenvwrapper, still hosted by our
friends at bitbucket.org. The issue tracker contents have been migrated
along with the source code.

The old Mercurial repository is still available at
https://bitbucket.org/dhellmann/virtualenvwrapper-hg until I’m entirely
certain that the new repository is working correctly.

Book Review: Pro Git

We are considering moving off of Subversion for version control and
so I have been investigating more modern DVCS tools such as
Mercurial and git. I use Mercurial for all of my personal
projects, and feel fairly comfortable with its basic work-flow. I
wanted to pick up a book on git, and the number one recommendation
when I asked on Twitter was Pro Git by Scott Chacon.

Quick Review

Inspired by Gene Ambaum and Bill Barnes’ review short-cuts, here’s my
review for the impatient reader:

Why I picked it up: I needed to learn more about git to decide if
it was the right tool for us and how it would fit into our work-flow.

Why I finished it: Chacon’s writing is clear and engaging. He
covered all of the tips for using git that I wanted and then included
some implementation details that are useful for understanding DVCS
theory, but not absolutely necessary for using git.

I’d give it to: A developer learning or evaluating git, or
researching DVCS tools in general.

Available Formats

The content of Pro Git is available for free from progit.org.
There are download links for the PDF, Mobi, and epub editions, or you
can browse the HTML version on-line. I purchased the paper edition,
published by Apress. It isn’t entirely clear which version is more
up to date, though, since the PDF I downloaded only contained a
placeholder for chapter 1 (“Introduction”).

Contents of the Book

Chapter 2 gives an overview of version control system types to explain
where git fits in. It also covers the features of git that make it
different from centralized tools, and explains why the data model used
by git ensures the authenticity of a repository’s contents. It
concludes with instructions for installing git and setting up your
first repository.

Chapter 3 explains how to use the basic features of git for adding
files to a repository, modifying them, tracking those changes, and
distributing the changes to other repositories. Branching, a
fundamental concept in git, is covered in chapter 4. The book covers
the basic mechanics of creating and working with branches, as well as
suggested work-flows for using them effectively.

Chapters 5 and 6 talk about collaborating with git. Chapter 5 shows
how to set up a central git server. Three options are discussed, ssh,
HTTP, and git’s own protocol. I only skimmed this material because it
was not relevant for my evaluation. Many other readers working on open
source projects will probably be able to skip it, too, since it is
easy to set up public repositories on hosting sites such as Github.
Chapter 6 covers distributed work-flows for sharing code with other
developers. It includes several common scenarios such as maintaining a
central source, using lieutenants to screen changes before they go
into trunk, etc. This information was very useful for my evaluation
because I was able to see immediately how my company’s work-flow would
map to git’s feature set.

Chapter 7 goes into detail about some advanced usage features. I
expect this information to be more useful after we have been using git
for a little while. Chapter 8 is about options for customizing git,
from basic settings like your identity, to server-side hooks for
automating changes on deploy. Chapter 9 talks about how to use git
with other version control tools, either as a way to import data into
git or by using git as a front end for systems such as subversion.

Chapter 10 covers internal implementation details of git. I found this
information interesting, but it probably isn’t that relevant for
someone who just wants to use the tool.

Review

Pro Git is an excellent book. It is clearly written, covers all of
the information you need without introducing any unnecessary
complications. When I looked at git several years ago the information
I found on-line was confusing and turned me off. After reading through
Pro Git and experimenting with some of the examples I felt ready to
move all of my source code into git for safe-keeping. I don’t
anticipate needing another book to explain any more details about
using git as a version control system.

I expect to keep Pro Git handy as a reference as we plan the
migration of our source code repository from subversion to git, and
for a while afterward, until the commands I need to use become
ingrained.

virtualenvwrapper.bitbucket 1.2

What is virtualenvwrapper.bitbucket

virtualenvwrapper.bitbucket is a template for
virtualenvwrapper to extend its project-management features.
It automatically clones a BitBucket repository when creating a new
project directory.

Refer to http://www.doughellmann.com/docs/virtualenvwrapper.bitbucket/
for details.

What’s New in 1.2?

This release shifts from requiring virtualenvwrapper.project to using
the new version of virtualenvwrapper that includes the project
management features.

PyMOTW source now available on BitBucket.org

Earlier this week I uploaded all of the history for PyMOTW to
BitBucket.org.

BitBucket uses Mercurial as its DVCS, and after a couple of hiccups
with the initial conversion I’ve had pretty good luck. I think I have
the workflow down far managing local changes vs. updates pushed to the
central repository.

I still need to work out how (and whether) to use branches. I have a
sense that I can use local clones in the way I used to use branches:
starting an article that was going to take several sessions, without
committing the changes to the trunk. What are the typical practices for
hg branching? Do people use them?

Today’s PyMOTW post is the first post since the change-over. If you
encounter any problems, please report them as an issue via the BitBucket
issue tracker.

Moving PyMOTW to a public repository

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:

  1. Google Code (svn)
  2. Bitbucket (mercurial)
  3. Launchpad (bazaar)
  4. 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.