DVCS
I've just pushed the first commits to my newest (public) coding project: genosha (no apologies for the name at all ;> ). A pretty small one, but it's been kind of fun to do. While the other project I've opened up to all comers (terbium) has application for general computer users (despite its lack of point-and-droolness, it's actually reasonable easy to use), genosha is a lower-level tool. So I won't be upset if this post causes much glazing-of-the-eyes for those on my friends-list.
This increase in publicly visible coding is intentional. I have started many projects that have never gone very far. Some times this is for obvious and good reasons. Others for just plain inertia. This way, there's at least some sense of completion and progress.
In putting together genosha, I was faced with a bit of a dilemma. A very geeky one. Which source control system would I use? There are a fair number out there. From the beginning, it was obvious it would be a DVCS (Distributed Version Control System). That limited it to a handful of contenders. In fact, though, it comes down to a choice between two: Mercurial and git. A quick look at some of the others (bazaar, monotone, arch, darcs, etc.) and how they were being used disuaded me from them quickly.
Both Mercurial and git stem from the same period: the Internet/Linux drama around BitKeeper that ended in the owners of that proprietary software withdrawing the gratis version that allowed the Linux kernel developers to use it. Mercurial and git were primarily responses to this.
In many respects, they are quite similar. If I were to get involved in a project that used either system, I'd be quite content to work along. But this was about choosing ones for my own use.
External hosting options exist for both. Git has github, gitorious, and a myriad of others. Mercurial has Bitbucket, code.google.com (Real Soon Now), and others. Likewise, both have significant projects using them. Git has the Linux kernel, WINE, x.org, and many others. Mercurial has Mozilla, Xen, and (when they get the migration from SVN figured out) Python. Mercurial is written in Python (with some use of C where important), git in C and Perl. This might give Mercurial a slight advantage; its internal structure is cleaner, and (to my Pythonic eyes) more readable/understandable. However, I don't want to futz with the thing; just use it to manage my own projects.
As I said, they both are fairly similar. Well. At the higher levels I'm looking at. They are, however, not identical. In the end, I (obviously from the genosha link at the top) settled on git.
There are two main differences that tipped the scales. The first is that Mercurial does not natively support "local branching". I've found this immensely handy in git; not needing to manage separate working directories for very lightweight, temporary branches. There is a Mercurial extension for local branches. To me it seems... a little hack-y.
The other difference that weighs in git's favour is its concept of staging. Files/changes to be committed in a changeset must be added to the staging area (it's a simple command, or an option when you do your commit) prior to being committed. I find this very useful as I like (to try at least) to keep my commits geared to one task. However, when actually doing that, sometimes other little changes creep in. Staging allows me to keep them separate without a lot of extra bookkeeping. Mercurial doesn't have this concept.
Now I know that there are workarounds for both of those. However, I don't like the workarounds, and feel that the more non-mainline the installation is, the more likely I'm not using the tool in the Proper Way (as it was intended). To be sure, there are a few other minor differences but I considered those mostly noise.
I expect I'll probably end up working with Mercurial eventually. This would not be a bad thing. It's a good DVCS, and I would recommend it, certainly over something as painful as SVN. It's just not quite right for me.
This increase in publicly visible coding is intentional. I have started many projects that have never gone very far. Some times this is for obvious and good reasons. Others for just plain inertia. This way, there's at least some sense of completion and progress.
In putting together genosha, I was faced with a bit of a dilemma. A very geeky one. Which source control system would I use? There are a fair number out there. From the beginning, it was obvious it would be a DVCS (Distributed Version Control System). That limited it to a handful of contenders. In fact, though, it comes down to a choice between two: Mercurial and git. A quick look at some of the others (bazaar, monotone, arch, darcs, etc.) and how they were being used disuaded me from them quickly.
Both Mercurial and git stem from the same period: the Internet/Linux drama around BitKeeper that ended in the owners of that proprietary software withdrawing the gratis version that allowed the Linux kernel developers to use it. Mercurial and git were primarily responses to this.
In many respects, they are quite similar. If I were to get involved in a project that used either system, I'd be quite content to work along. But this was about choosing ones for my own use.
External hosting options exist for both. Git has github, gitorious, and a myriad of others. Mercurial has Bitbucket, code.google.com (Real Soon Now), and others. Likewise, both have significant projects using them. Git has the Linux kernel, WINE, x.org, and many others. Mercurial has Mozilla, Xen, and (when they get the migration from SVN figured out) Python. Mercurial is written in Python (with some use of C where important), git in C and Perl. This might give Mercurial a slight advantage; its internal structure is cleaner, and (to my Pythonic eyes) more readable/understandable. However, I don't want to futz with the thing; just use it to manage my own projects.
As I said, they both are fairly similar. Well. At the higher levels I'm looking at. They are, however, not identical. In the end, I (obviously from the genosha link at the top) settled on git.
There are two main differences that tipped the scales. The first is that Mercurial does not natively support "local branching". I've found this immensely handy in git; not needing to manage separate working directories for very lightweight, temporary branches. There is a Mercurial extension for local branches. To me it seems... a little hack-y.
The other difference that weighs in git's favour is its concept of staging. Files/changes to be committed in a changeset must be added to the staging area (it's a simple command, or an option when you do your commit) prior to being committed. I find this very useful as I like (to try at least) to keep my commits geared to one task. However, when actually doing that, sometimes other little changes creep in. Staging allows me to keep them separate without a lot of extra bookkeeping. Mercurial doesn't have this concept.
Now I know that there are workarounds for both of those. However, I don't like the workarounds, and feel that the more non-mainline the installation is, the more likely I'm not using the tool in the Proper Way (as it was intended). To be sure, there are a few other minor differences but I considered those mostly noise.
I expect I'll probably end up working with Mercurial eventually. This would not be a bad thing. It's a good DVCS, and I would recommend it, certainly over something as painful as SVN. It's just not quite right for me.