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 < 150 MB are free, so that should cover my needs for this project.
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.
34 comments:
They all sound like good choices to me. Svn seems like the path of least resistance. A distributed system, OTOH, has the advantage that every clone is also a full backup of the repository, which is nice.
I'm a long-time subversion user though I use svk on my netbook to give me the ability to work offline.
I've recently moved some of my things to github and have been very impressed with git. I've played with hg but have had issues installing it on my systems. Bzr hasn't impressed me yet.
How much content are we talking here? How many changes do you expect from others?
Coming from subversion, I found git very easy to pick up. I haven't tried mercurial or bazaar. Merging and branching in git is much easier, in my opinion. Git also has support for converting from a subversion repo.
You can have unlimited public repositories on BitBucket. The limitation of one repository you're thinking of is for private repositories.
Google Code doesn't have the social networking aspect that those other hosting sites do, which I find particularly interesting. People can fork your project, work on their own patches, and send them back to you if they so please.
I have read that Google Code is considering adding support for a DVCS, though I think it's still a mystery as to which one it might be.
If you mess with Mercurial some more I recommend fiddling with all of the extensions it comes with. There are quite a few interesting ones. Some that I personally use are alias, color, convert, graphlog, mq, patchbomb, rebase, record, and transplant.
Mercurial's branch support can be confusing. It supports intra-repository branching, which it calls named branches. You use these for long-lived branches, e.g. default (stable) and unstable. When you want to prototype something outside of your main repository, you just clone the entire thing locally. Mercurial will make hard links for the underlying repo data, so it doesn't use up double the space, and you can push and pull between the repos.
@benpsm - I have a couple of people doing (or offering) translations at this point. While I don't necessarily expect direct submissions to the English version, that isn't out of the question (especially with patches to update articles about modules with updates, hint, hint).
There are around 900 files in the repository now, maybe a few more. That includes the .rst and .py files, as well as build instructions, templates, etc.
@Brodie - Ah, the distinction between public and private wasn't clear. Do you know if the 150MB limit still applies to the public repositories? I'm not in any danger of approaching that amount of space, yet, I'm just curious.
@Jason - I'm going to experiment with importing the svn data into a git repository the next time I have an afternoon to work on this. It sounds like it has the features I want, I'm just concerned about whether I'll be able to wrap my head around the UI. Only experimentation will tell that.
.. a vote for Google Code and SVN
I recently moved Paver from Launchpad to Googlecode because Googlecode has a much simpler interface (plus the minor additional benefit that more people are more comfortable with subversion). Most importantly, the bzr-svn plugin works well enough that I felt I could do that reasonably. bzr-svn means that people who want to use a DVCS can, and people who want to stick with svn can.
(Personally, I find bzr and hg to have command structures that are easier to adapt to from svn than git's command structure.)
Bitbucket has two great advantages: Mercurial, and Jesper, the chief developer, who is extremely attentive to people's requests and a pleasure to work with.
Google Code (if you can stomach svn, who is definitely NOT a match for hg) has one great advantage, the built-in code review system: very bare-bones, to be sure, but still a pleasure to work with compared with reviews by email, and far more convenient than non-integrated approaches (such as running rietveld on an appengine instance).
Having only lightly tried git and bazaar I must admit I have no idea why I would use either of them in lieu of hg, which appears to be an excellent system. I have no experience with the two sites you mention as possible hosts for them, anyway.
+1 for Google code.
We've been using git for all new projects here.
It's not too rough to get started with and it does have a lot of little niceties that are hard to describe.
Anyway, I find myself really liking it the more I use it.
oh, and to be more specific, here is http://www.catalyst.net.nz/
--a gang of 80 or so developers with a strong open source orientation and a large number of small to large sized dev project going on
git has become the thing of choice here--and we never agree on _anything_
Doug,
(Jesper here, author of Bitbucket),
The 150 MB *does* apply to your public repositories as well, although I'd be more than happy to grant you more space, if what you're doing is open source. I know there's some confusion as of to the number of repositories and space at the moment, and I'm the process of clearing that up with some shiny new pages.
@Alex - Bitbucket is looking promising. I like the simplicity of the site's interface, much as with Google Code. We use svn at work on a large code base, so I'm used to it. I'm a little afraid if I start to like hg I'm going to hate working with svn during the day! ;-)
I have to admit, I'm a little surprised at the level of support svn is seeing in the "voting" here. I *like* it, but I thought all the cool kids had moved to DVCS already.
@Reed - It's going to be another week or so before I can cozy up with the git manual. It's not out of the running, but doesn't seem like the path of least resistance.
@Jesper - Thanks for the offer! I'm *way* under 150 MB right now, so I'll worry about the limit if I start to reach it.
At this point I'm want to make sure I understand the hosting options, which I think I do now. I saw the limit on "private repositories" but didn't understand the distinction (since there was no indication of a "public" repository limit, other than space). Maybe linking the word "private" to a description of the two types of repositories would help clear that up? Or maybe I just didn't read the page closely enough and that description is already there.
I know Georg has had good success with Bitbucket hosting for Sphinx, so I'm taking that recommendation seriously.
About public/private repositories on bitbucket.org: a private repository is a secret repository, visible only to yourself and other users which you have explicitly given read/write permission.
A public repository is readable for everybody and writable for the users you have given explicit permission.
I've used bitbucket for public and private projects, and it gives a very easy way to share source code with others.
Another thing: the history in Mercurial is a directed acyclic graph (DAG) where each node is a changeset and each edge is a parent-child relationship.
When you 'hg clone' you copy this DAG from one place to another. Each clone is separate and can be considered forks of each other. When you make new commits in each, their DAGs will start becoming different.
You can still pull changesets between them. This simply means that the DAGs are compared and any missing changesets are transferred.
For your backup you could make a clone to somewhere else. Lets surpose you call your repository 'trunk' on your machine. First we clone it to a remote host:
hg clone trunk ssh://host/backup
You can still make local clones for your various purposes:
hg clone trunk branch-a
hg clone trunk branch-b
You do your work in your branches:
cd branch-a
# work, work, work...
hg commit -m 'Nice work.'
cd ../branch-b
# work, work, work...
hg commit -m 'Good job!'
You can push your changes to your backup location:
hg push -f ssh://host/backup
cd ../branch-a
hg push -f ssh://host/backup
The -f flag is necessary on the first push since we use the same backup location for both branches which means that the history in the backup repository will contain multiple heads. It is normally considered "polite" to pull in and merge such heads before pushing changesets to a central repository. But in our case we don't want this, we really do want the remote repository DAG to contain two heads, one for branch-a and one for branch-b.
The backup repository shows that it is possible to work with several branches in Mercurial without making several clones. The new "bookmarks" extension for Mercurial 1.1 makes it easier to keep track of such multi-headed repositories.
But you can even do it with plain hg. You use 'hg update' to make the files in your working copy reflect a given changeset, typically the one called 'tip'. But you can also specify any other changeset in the history DAG, such as another head. Use 'hg heads' to learn about the available heads and use 'hg view' (from the hgk extension) to get a graphical overview.
Hmm, lots of stuff for a blog comment :-) My main point is that Mercurial has a very simple, yet flexible history model.
@Martin - Wow, very clear description. Pushing changes from multiple branches into the same repository wasn't obvious as the way to share them -- I'm too used to svn's "a branch is a copy" model, I guess. The whole "multiple head" thing is still a little confusing, but I think the only thing to be done about that is for me to actually *do* it a couple of times.
I use Bitbucket for a while now and I strongly recommend this option. Perfect ratio of features vs. noise and help from irc is just great.
@Doug: thanks, I was a bit afraid of explaining the DAG stuff like this without pictures :-)
I'd like to add my vote for using bzr on Launchpad. I've used all four of the choices extensively, and have found bzr to be the easiest to use for anyone, regardless of their VCS background.
I haven't used any of these systems (still using svn at work, don't have any experience with DVCS)
but maybe this link will help (link to Bruce Eckel's weblog, discussion about BitBucket vs. Lunchpad)
http://www.artima.com/weblogs/viewpost.jsp?thread=242653
Thanks, Ido, that's a helpful link. There's a little bit of vagueness in the "just feels better" part at the beginning, but the info about how Bitbucket automatically packages releases for you sounds like an interesting feature.
I've used Subversion and Git long enough to know that a DVCS like Git is the way to go. I wouldn't even bother considering Subversion if I were starting a new project. Mercurial, Git, and Bzr are excellent tools. However, if I were asked to pick one out of those I'd pick Git simply because of the beauty of the tool and the ease-of-use (yes, ease-of-use). Git is just as simple to use as hg or bzr. Git is now so easy to use even our designers use it. Of course, additional tools like tig help. Perhaps a little patience will get you a long way. Don't give up on git.
The svn repo for gedit (GNOME Text editor) is over 2 GB in size on the server. I cloned the whole thing into Git and it was less than 45 MB. Yes, 45 MB. I should also mention that git is VERY fast.
One of your primary concerns, I've read, is branching. Branching is as easy as it gets with git. Just checkout a particular commit as the start of a branch, work on it, and when your branch is good enough, just merge it back into master. Pretty painless merging and branching.
I'd say go for git.
Hello,
to my opinion bzr has high cross-platform advantages.
The explorer integration on Windows has almost similar functionality as TortoiseSVN.
Remember that many users are beginners and from various background.
I think any beginner can issue this command (even on Windows):
git clone git://github.com/foobar.git
Here's a link to git for Windows.
http://code.google.com/p/msysgit/
Git works extremely well on Linux and OS X. Programmers shouldn't be afraid of the terminal. :-)
At this point there's enough positive support for all of the various tools that I am convinced I need to try each of them. Thanks for giving me your opinions.
Does anyone have anything to say about any of the hosting services?
I would say that no matter which hosting service you take, with a DVCS, you aren't tied as much to it as you would be with a VCS. If your host disappears overnight, you lost absolutely nothing and can easily switch to another one. With a VCS, if you lose your host, you lose your history.
Dan, that's an excellent point. I guess local backups are as simple as cloning the repository in the standard way, too, so that would be straightforward to script.
I haven't used bitbucket, but I can recommend Mercurial.
I was a CVS user. Got convinced at PyCon 2008 that I should look at DVCS. Spent a couple of hours there in a bzr tutorial session. Went away and spent some time reading about git vs. bzr vs. hg and decided to try hg first because it seemed the best fit for small-medium project that I work on. Very happy with the decision, and have converted several projects from cvs to hg with no trouble.
As others have said, the easy of creating branches with DVCS is a big plus for refactoring, debugging, isolating development of new features, etc. - though I still find I have to remind myself to do it - old CVS habits die hard.
It's also cool that every clone is an implicit backup.
You can also try out hgview as an nice alternative to “hg view”, quicker, nicer UI, a few extra functionnalities : http://www.logilab.org/project/hgview
Have you decided on what you are using.
I'd love to hack around in your source as they are really great examples.
@Martin - Unfortunately, no. The holidays turned out to be a lot busier than I anticipated, so I didn't have as much time to try out the various services as I had hoped. I may just take the plunge with one, and move later if I decide I hate it. I'll definitely be posting about it when I do make a decision.
Post a Comment