A quick post today because I didn’t find an easily accessible reference for building Git from source on Mac OS X El Capitan, and I needed to. Maybe there’s another post out there just like this one, but I didn’t find it, so maybe this will be useful in future for those who similarly come up short on Google. After you’ve cloned the source from https://github.com/git/git, open up a terminal. I’m assuming you’ve got Xcode installed, and that you’ve already installed the command line tools - if not, execute this on the command line now:
I was thinking the other day about how many version control systems I’ve made my way through over the years of being a professional developer, and I figured it would be fun to put it in graph form. Of course, this is entirely from memory and gives the illusion of being more empirical than it actually is, but hey, everyone loves graphs, right? Yes, I really didn’t use any source control back in 1994, barring backing up to 3.
I’m pleased to announce that I’m finally ready to make my first fully-fledged commercial Mac OS X application available to the world! SourceTree is a user-friendly Mac OS X front-end for Mercurial and Git, the two most popular distributed version control systems used today. The goal was to create a single tool which could deal with both systems efficiently, and to give a developer quick and intuitive access to the things (s)he needs to just get on with building software.
So, I’ve just about completed my practical experiments & review of Mercurial and Git.
In the end, I had far too many separate notes and sets of experiences to post, so I boiled the argument down into the 10 most important factors to me, and scored Mercurial and Git on a scale of 1-5 based on what I’d found when using them. Here are the (annoying) results:
|1||Ease of use - command line||4||5|
|2||Ease of use - GUI||4||4|
|3||Platform support - core||3||5|
|4||Platform support - GUI||4||4|
|5||Web Host Functionality||5||4|
|6||Reliability & error handling||3||5|
|10||OGRE Community support||5||4|
I’ll explain the scores, and my conclusion, after the jump.
Git is picky when it comes to converting large, moderately complex Subversion repositories and so far the only option I’ve found that works reliably is using the very latest version on Linux. Forget about using 1.6.5 on Windows via msysGit, at least for the git-svn conversion it’s very, very unreliable. Similarly I found Git 1.5 on Linux very flaky for the svn conversion. This doesn’t give me the greatest confidence in Git but in order to properly explore all the angles, I’ve committed to making it work even if it means I have to monkey about a bit.
As you know I’ve been reviewing DVCSs lately. I’m taking my time doing real use cases on them, and deliberately not doing the sort of feet-first leap into whatever looks best / most popular on the surface because I don’t particularly want to discover unexpected problems down the track. It’s consuming a lot more time than I expected - I’m writing up my findings and may publish the entire results later on if I can find the time to clean them up and format them better, but for the moment I thought I’d share some experiences with the conversion process of a relatively large, long-lived, multi-branch repository (OGRE) from Subversion to Git and Mercurial, because that’s what I’ve been wrestling with in the last few days.
A few weeks ago I decided to start seriously investigating switching to a DVCS. I’m currently up to my eyes in work and haven’t really had time to progress that in the last few weeks; however some absolutely abhorrent performance / reliability problems with Sourceforge’s Subversion server made a large merge process so costly to me (in the end I had to commit in small chunks, breaking transactional consistency, and it needed so much babysitting because of the speed / reliability it took me 4 bloody hours just to commit!
Ok, so I’ve posted my initial feelings about tinkering with Mercurial and Git, and that seems to have generated some interest. It’s time to get a bit more formal about how I’m going to evaluate them against each other, to decide which one I like to use most in real, practical scenarios. So, I decided to come up with a list of use cases for the things that I typically have to deal with when managing the repositories for a software project (open source and otherwise), so that I can methodically test them out and see how I feel about each system.
I’ve been interested in DVCS for a while; having done my fair share of branch management, something which makes that process easier and more transparent is definitely very attractive. I particularly like the way a DVCS makes it easier for people to collaborate in pockets of their own, away from the centralised environment, and track other repositories and keep their local mods up to date more easily - public-branch-on-demand if you will.