Dee Vee See Ess (DVCS)permalink
» 01 Mar 2009
In a typical flurry of “scratch my own itch” combined with “shaving a yak”, I’ve spent the better part of the last couple of days researching DVCSs (distributed version control systems). At my current employer, we use Subversion as a VCS and as has been documented ad nausem, Subversion is getting a little dated.
My personal two biggest issues are branching and merging (no surprise) and the ability to locally branch / hack / merge without impacting anyone else. I was tweeting about this recently and got an expected response from a source hosting provider – I needed to look beyond Subversion.
My top three candidates were obvious: Mercurial, Git and Bazaar. Mercurial was recently chosen by Sun to provide SCM for their open source and some of their internal projects. Git is the flavor of the week/month/year due to Linus moving the Linux kernel to it, and Rails moving to it as well as the now renowned GitHub. And Bazaar hosts the great Linux distro Ubuntu as well as hosting MySQL. So all three indicated plenty of longevity and backing. My personal breakdown went something like this…
Mercurial
This was my initial favorite. A cursory review indicated a simple, straightforward command set. Sun was moving most of their external open source projects and some internal projects to it, and since my ‘day job’ was in Java, I was likely to run into Mercurial increasingly in the future. I downloaded Hg (the abbreviation for Mercury, also Mercurial’s command line) onto my iMac and asked a fellow developer to do the same. It installed perfectly, I did my first “hg init; hg add; hg commit -m ‘..’” and it all felt great. I then started an “hg serve…” up and browsed the repository from Safari. All seemed to be going flawlessly. I sent the URL to my repos to my co-worker and asked him to do an “hg clone url”. It pulled down fine, and he was able to make modifications and commit with no issues. I should have known it was going all too well. I then asked him to do an “hg push” to push his commits up the original repository. He was greeted with “remote: bash: command ‘hg’ not found”. This issue is actually noted on the Mercurial website, but in my Google conditioning, I Googled it and it led me down a rat-hole of /etc/profile and /etc/bashrc tweaking to try to get things to work. I could of course symlink ‘hg’ to /bin and get things working but it just felt like such a hack. Thus my first ‘yak shaving’…
Bazaar
Frustrated by the inability to find a workable solution to my Mercurial issue, I started looking at other options. Since I had previously reviewed Git and thought it too difficult to grok at the time, I looked at the next alternative, Bazaar. There were a lot of appealing things about Bazaar. It had a similar syntax to Subversion which I was already familiar with. It allowed full directory versioning including empty directories which neither Mercurial or Git allowed. It seemed more thoroughly documented than Mercurial. It was backed by an actual company (Canonical) rather than a single person. I setup a ‘test project’ repository, ‘bzr init; bzr add; bzr commit -m ”…”’ and I had a local repo. When it came time to publish things got ‘interesting’. By default, Bazaar can use a ‘smart-server’ which sounded like ‘svnserve’ so I decided to avoid it for now. But the only other option was ‘SFTP’. I pushed to an SFTP url (which is enabled by default when you enable Remote Login) and then pulled from a remote machine. I had no issues, but I clearly had no idea what I was doing with SFTP as setup on a Mac. I managed to create a ~username directory somewhere off ’/’ in the server location ‘accidentaly’. This led to obvious disappointment as I wanted to setup a VCS … not a VCS+SFTP in a Mac environment. To top that off our dev server is Fedora and our QA and Prod servers are Windows (don’t ask – it’s painful enough). I didn’t enjoy the thought of trying to configure SFTP on these environments which were surely different than Mac OS X. On to the final ‘yak shaving’…
Git
I was familiar with GitHub (being as much into Ruby personally as I was into Java professionally), but Git still felt uncomfortable. I had looked at Git back just before the time that Rails stated they were migrating. At that time, I think Git was either late 1.4.x or early 1.5.0.x. Git was pretty daunting at the time, having a ton of commands to seemingly grok to just understand what Git even was. I decided to do some Googling (catching a pattern here?) to see if the state of things had changed. Curiously, I ran across Scott Chacon’s blog post ‘On Mercurial’. After reading his post, I realize that maybe I was over complicating Git by assuming that I needed to know all 150 Git commands to be productive. I decided to give Git another shot. “git init; git add .; git commit -m ’…’” – it all felt strangely familiar. I moved to my remote host and did a ‘git pull ssh://user@host/code/ruby/dir’ and promptly receive an error. My heart sank. I decided to google the error with “git-unload-pack: not found” error and it immediately returned the first link on what I needed to do – add a ‘PATH=/path/to/git’ to my .bashrc. I tried it and… it just worked. I had easily replicated what I was trying to do with the other two VCSs all day. So my decision was made by attrition. Could have I gotten the other two systems to work had I tried something similar? Probably, yes. Did I want to Google a solution for ‘git’ every time I wanted to fix something with ’VCSofchoice’? Hell no. I’m a developer, after all, not a release manager.
So come Monday morning, I’m going to try to institute Git at work for version control. As a bonus, some additional reading revealed that git-svn support is plenty good enough to entertain switching, even if gradually. More soon…