./databyte


Git? Mercurial? Or does your DVCS really matter?

There is much talk on the social networks such as Twitter and Blogs regarding Git over Mercurial and vice-versa.  If you don’t know much about Distributed Version Control Systems (DVCS), you should just browse the home pages of Git and Mercurial then head over to Wikipedia’s entry for DVCS.

Besides rampant personal opinion, there are two good write-ups that I’ve found comparing the two packages.  Neither article is completely accurate but the comments do shed light on the inaccuracies.

Let’s start with Google’s DVCSAnalysis for Google Code.  The main inaccuracy in this document are rebasing support added to Mercurial (which is noted after the point) and the last two bullet point under Mercurial advantages which can be overcome by configuration within git.

The third bullet point under Google’s analysis concerns maintenance of git repositories.  First a little research on why you need to ‘git gc’ which summaries to the need of removing duplicate objects and compacting objects in your git repository.  This is where git’s configurations come into play.  In particular, you can ignore the need for maintenance by running:

git config --global gc.auto 0

The fourth bullet point under Google’s analysis concerns history not being sacred on git repositories.  This can only occur if you force a push.  As noted in the comments, you can run this command on the server to disallow such actions:

git config --system receive.denyNonFastforwards true

The other good write-up I found was by the Python core team when they chose a new source control for the Python project.

They did a great job of writing out scenarios and a sample set of commands for each VCS to compare.  For me, “Backport” looks complicated in git whereas “Separation of Issue Dependencies” looks complicated in anything but git’s stash command.

Their final points conclude three reasons for choosing Mercurial over git.  The first point is an obvious pain point for Windows users of git - there just isn’t any good support for git under Windows.  The other two points are not as applicable to the general developer but you can read the article to see if they apply to you.  For one, I’m not partial to if the underlying software was written in Python or not but, obviously, the Python core team feels differently to use tools written in their language of choice and I can completely understand their position.

In the end, the similarities between the two systems are so profound that it’s my personal belief that both systems are very solid and neither is the wrong choice.  They were both started at the same time (2005) for the same reasons (as a replacement for BitKeeper).  If you need great HTTP support or Windows support, Mercurial is a much easier path.  Git has found good communities in the Linux Kernel and on GitHub.  With the use of Mercurial for Google Code and Microsoft CodePlex, the community around Mercurial is growing and growing fast.  You can’t go wrong with either choice and you’ll probably need to use both if you’re an active developer in the community.

Someone doesn’t have to lose for another to win.

Edit: (2010-04-22) Another great site: http://whygitisbetterthanx.com/

Edit: (2010-04-23) This is the ultimate answer: http://gitvsmercurial.com/


Technology 10+ years ago

I’m moving out of a house that I’ve spent almost 10 years in, with boxes from before then. This time, I’m being a little pickier with what I bring since it’s NYC and space is at a premium.

While going over boxes of “junk”, I’ve noticed:

  • JavaScript hasn’t come too far from the basics back in 2000.
  • I’m glad I don’t have to program in COM or, worse, DCOM anymore.
  • PGP never really took off like I thought it would.
  • I miss OS/2.
  • I sure did have a lot of dial-up and telnet hosts written down.
  • PixiNet was my first real ISP in Hawaii after local dial-up modem banks and MILNET (part of the old DDN).
  • Apparently over Christmas break during ‘99, I printed out a list of all known ports (119 pages) and started figuring out what each was for and known vunerabilities of each.
  • Man did I print a lot, good thing I have EverNote now.
  • I still miss OS/2.

Growl 1.2 installation stuck at Preparing Growl

Turns out if you have the iPhone Simulator running when upgrading Growl, it will get stuck while Preparing Growl for installation.  The hangup occurs as the installation process starts after the Package Installer has taken in your input and authenticates your Admin rights.

Looks as though the iPhone Simulator conflicts with any Package Installer over at Open Radar.

Apple tries too hard to keep their iPhone OS under lockdown under SDK conditions knowing that jailbroken phones exist.  They should open it up.  What’s the concern?


Earlier →