Tim Boudreau is a noted technology consultant, evangelist and author. While perhaps most broadly known for his leadership on Sun Microsystems’ NetBeans, those who’ve worked with Tim remark most on his technical chops, passion for a great challenge and rare gift of great communication. And, as a former troubadour, he’s pretty tough when it comes to bad 70s rock lyrics too. A real renaissance programmer. Tim has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

Switching to Mercurial

01.29.2008
| 21301 views |
  • submit to reddit

When I first heard that NetBeans and OpenJDK were going to switch to a version control system I'd never heard of called Mercurial (aka Hg) I had some reservations.

Well, this weekend, we did the switch - all the sources of NetBeans are now housed in Mercurial at https://hg.netbeans.org - and I also spent Saturday setting up my own Mercurial server at home from scratch and putting a bunch of code in it and working on it. It was incredibly easy to set up!

To my surprise, I'm really liking it a lot. Here are some of the reasons:

  • Checkouts are much faster than CVS - and that's pulling down the entire history of the repository, not just the trunk - so it's faster for pulling down more stuff
  • Since you have the whole history, you can do any sort of historical diff, merge, patch or rollback you want without a network connection
  • If you want to try something that you might want to roll back, cloning your local repository is very, very fast (Mercurial takes advantage of Unix and NTFS hard-links, so you're not copying tons of files)
  • Setting up a repository is as simple as typing 'hg init'
  • Setting up Apache to serve it is pretty darned simple; in a pinch you can just type 'hg serve' to move some stuff between, say, a laptop and desktop (ever set up a CVS server? Or just tried to find documentation on how? It ain't pretty)
  • Creating a branch is just cloning your local repository (more on that in a moment)
  • It's not about file versions, it's about one commit being an atomic unit (ever needed to figure out from CVS, gee, I need version 1.52 of this and 1.3 of that - files are just the wrong unit of graularity)
  • Each commit can be uniquely identified by an SHA-1 hash
  • If you know the hash of the commit (easy to get), you know what versions of everything else it was built on top of

Things that are different than CVS or Subversion:

  • Mercurial is a distributed VCS. You have a local repository that you commit a changeset to. Then you push changes to some other repository (might be a local path or a http or ssh url), or you pull changes from a remote repository.
  • No repository is king - there is no concept of a master repository except by social agreement that that's where everybody puts stuff
  • If the network is slow, you can easily have a periodically updated local mirror
  • Easy to chain repositories - push to a repository that runs tests or some other analysis and then if they pass pushes the changes on

Things that seem less good than working in CVS:

  • If you want to work on a branch in public, you need to get the repository from that branch up on the web somehow (not that hard to make this easy, just the social risk that old, long-since merged branches will pile up in such a tool and make things hard to find)
  • Because everything lives and dies by hashes, if someone pushes changes to files you haven't changed, and you want to push changes to other files, you have to pull all the changes from the remote repository before you can push yours. One of those things where it's fine unless everybody flushes the toilet at once, which might happen around the end of the day when it comes to pushing changes.
  • The NetBeans integration modules isn't quite ready for prime-time (but with 200 developers using it daily, I expect it will improve quickly)

All and all, I am very happy about this change. Have you used Mercurial? What do you think? I'm sure there are gotchas I haven't forseen - anything that changes workflow for a few hundred people is disruptive. But so far it's been a remarkably smooth transition.

 

Published at DZone with permission of its author, Tim Boudreau.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Hicks replied on Wed, 2008/01/30 - 8:41am

I have not use it. I am kind of waiting to see how the git/mercurial/bazaar fight goes.

phil swenson replied on Wed, 2008/01/30 - 10:18am

Does Mercurial modify the client file system like CVS/SNV does (with the CVS/SVN directories)?  I find this to be the biggest weakness in the SVN system....  Makes large scale refactoring a pain.

My favorite SCM system is StarTeam, which doesn't mark anything read-only or modify the file system in any way to keep status - it simply scans the current files to see the status (unchanged, changed).  I would think eventually this model will move to FOSS as well.  

Also, does Mercurial have a decent client?

 

phil

http://philswenson.com 

Tim Boudreau replied on Wed, 2008/01/30 - 1:40pm in response to: phil swenson

Mercurial has one .hg directory at the root of the repository.  No CVS/ or .svn directories scattered all over the place.

 

Very nice since the sequence of deleting something in cvs or svn involves that weird business or sort of telling the vcs you intend to remove something so it can update its metadata.

 

One thing I truly love:
hg addremove -n
(see what would happen if everything deleted in your sources were removed and everything new were added), then
hg addremove
if the set of changes is good;  then commit.

 

NetBeans cvs/svn support sort of does this for cvs and svn,  but I can't count the times I've manually typed
cvs add foo/
cvs add foo/bar/
cvs add foo/bar/baz
cvs add foo/bar/baz/*.properties foo/bar/baz/*.java
-Tim

Mike P(Okidoky) replied on Wed, 2008/01/30 - 5:31pm

I love it.  Whenever I horse around with some test code, I can add version control to it effortlessly without getting distracted with "how was this done again" crap.

I then code away and can admire all the fantastic changes I've made that broke it. 

I have some questions, but I'm sure I'll figure it out at some point:

- I'm horsing around in a test directory, run 'hg init', and then after more changes, I've decided I want to make this test become part of my library collection.  The thing is that it needs to become part of some deeper subdirectory, whereas the initial test was just a directory of stuff (with subdirectories).  What's the procedure for moving the files plus its history over.

Mike P(Okidoky) replied on Wed, 2008/01/30 - 6:03pm

I'm seeing from http://wiki.netbeans.org/HgMigration#section-HgMigration-MigrateHistoryOrNot that it's possible to migrate cvs history to hg, with limitations.

Does anyone have any experience with migrating a large(ish) code repository? 

Tim Boudreau replied on Wed, 2008/01/30 - 8:20pm

My friend Jesse did a lot of the migration work for moving us from CVS to Mercurial;  it involved a massive source restructuring at the same time (getting rid of all project directories under other project directories because it had kind of grown like a weed that way for years and things were hard to find).  NetBeans is a pretty humungous codebase and it went without any problems I know of.  I'm sure it was a lot of work, but it sounds like the version control migration part was pretty easy.  If you email me privately I can put you in touch with him.

Tim BoudreauSenior Staff EngineerSun Microsystems

Dean Del Ponte replied on Mon, 2008/02/04 - 10:21am

I feel the biggest barrier to entry with Mercurial is setting up a server integrated with Apache.  Once that process is simplified, I think it will grow more rapidly in popularity.

Tim Boudreau replied on Fri, 2008/02/08 - 4:14pm in response to: Dean Del Ponte

Setting it up with Apache was pretty easy - my server is running Ubuntu, and I just got Apache 2 using Synaptic, then it was a matter of making a directory and copying a python file to index.cgi, and tweaking a couple lines of it.

The only thing that took much time and some surfing was setting up two virtual hosts, one with https and one without (you need to make sure you specify the port for each or they'll both try to initialize ssl and you get a cryptic error message).   If you don't care about plain http, that's not a problem - I just needed to serve some plain web pages too.

Tim Boudreau

Senior Staff Engineer

Sun Microsystems

David Brown replied on Thu, 2009/02/26 - 9:35pm

Howdy, I have an ANSI C daemon that I am very interested in further development. I have grown tired of using vi and a web based editor and ssh terminals to edit, compile (make), test-in-real-time as my SDLC. Rather, I would like to use my good ol' NB IDE. For some time I have only used my NB for Java but I installed the C/C++ plugin and I decided this is much superior to vi on a ssh terminal.

 This is what I have installed: hg (mercurial) on my public Linux box and on my local PC (both machines: command-line hg). The Linux box has two NICs and the PC is on the Class C part of the network.

 I have done a hg init on my ANSI C daemon source directory.

 This is what I want to do as a target goal: I would like to perform a hg clone of the Linux hg repository and have my NB mercurial plugin recogonize or pick-up on the local cloned hg repository so I can go-to-town on the source in the local hg repository.

 The local PC has as stated hg and ssh2 command-line executables. Unfortunately, I cannot get anything going from the PC command-line that is satisfactory or even informational enough to give me some clues as to what I am doing wrong.

 Any and all suggestions, hints, kinks, gotchas, rants, raves and/or flamings welcomed. Please advise, David.

Joshua Holmes replied on Fri, 2009/10/30 - 8:22am

I am reading up on Mercuial and Git both.. Obviously both come from similar origins in terms of spliting into their own projects and challenges they decided to face.. There is an interesting Google video

 It's pretty neat.  BUT I am coming from a Subversion world and I am still having trouble understanding what their getting at with a few things.

I understand that commits at internal, as-in they commit to my local machine.. But that begs the question if I have to commit files changed from a pull, and they update my local repository and then PUSH the files to the repository on the web ( my server ) what's the point?  Doesn't this add another layer of complexity?

 Even further, how come the netbeans utility for Mercurial AND for Git don't have a PUSH option?  Oh, I can commit until my heart is content but what good does that do me?  

Mateo Gomez replied on Wed, 2012/07/11 - 2:44am

i find this  switch complicated

mexican dip recipes

Matt Coleman replied on Wed, 2013/01/30 - 1:16am

Is it better to switch to Mercurial?

sell sheet designer 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.