Mercurial

From APIDesign

Revision as of 17:44, 20 September 2008 (edit) JaroslavTulach (Talk | contribs) (Redirecting to wikipedia:Mercurial (software)) ← Previous diff		Current revision (09:26, 12 August 2010) (edit) (undo) JaroslavTulach (Talk | contribs) (→Side note)
(5 intermediate revisions not shown.)
Line 1:		Line 1:
-	#REDIRECT [[wikipedia::Mercurial_(software)]]	+	[[wikipedia::Mercurial_(software)|Mercurial]] (also known as [[Hg]]) is a distributed versioning system.
		+
		+	=== Question ===
		+
		+	There are a couple of guys in the team that I am currently working in who
		+	would like to switch from [[Subversion]] to [[Mercurial]]. Since you have been through
		+	that already, I was wondering if you could give me some feedback on how it
		+	went. Did the migration go well, did you have any major disruptions, ... ?
		+	Any practical hints are greatly appreciated.
		+
		+	=== Answer ===
		+
		+	I am really glad we switched to [[Hg]]. Distributed systems are really great.
		+	However the transition period was not easy. While [[Subversion]] is for [[clueless]]
		+	developers, in the [[Hg]] world people have to think. And that is slightly
		+	unnatural for some of [[Chapter 1|these days programmers]]. One set of notes describing the issues can for
		+	example be found at [[Mercurial vs. Subversion]] page.
		+
		+	For a while people were complaining and making mistakes. But slowly most of
		+	them got over the problems and learned at least the basic commands to use [[Hg]].
		+	At that time I decided to make them more effective and we implemented
		+	[[netbeans:HgParallelProjectIntegration]].
		+
		+	This [[teamwork|workflow]] really uses the power of distributed versioning system. You can
		+	have a pyramid of repositories and builders and on each level you can ensure
		+	the commit breaks nothing essential. Mistakes done by individual developers
		+	are isolated and make little harm (in contrast to previous model when each
		+	error means to everyone: "stop the world" and fix it). I am really proud of
		+	this workflow, but my co-workers hated me for at least six months. Of course, I
		+	was really bad, I forced them to think a bit about [[Hg]], while they wanted to
		+	code.
		+
		+	These days the hate is mostly gone. [[Hg]] and [[netbeans:HgParallelProjectIntegration|parallel integration]] really makes
		+	us more productive. Once you get used to it, it is almost natural (throw
		+	some sarcastic comments in [[Talk:Mercurial|here]]). Definitely more natural than following
		+	practice of our new co-workers:
		+
		+	{{#ev:youtube|fVc_VPMsj7A}}
		+
		+	While I admire such cultural skills (I can't sing, I can just declaim), and maybe exactly because I sing horribly, my advice is clear: Use [[Hg]]! You will not have to learn to sing!
		+
		+	<comments/>
		+
		+	=== Side note ===
		+
		+	The [[netbeans:HgParallelProjectIntegration]] has been greatly inspired by a [http://wiki.glassfish.java.net/attach/V3BuildToDoList/GlassFish%20v3%20build.pdf presentation by Koshuke] about more distributed [[teamwork]] flow for Glassfish. The hierarchical delivery model fits naturally into distributed versioning
		+	system like [[Hg]]. However as Koshuke mentions at the end ''this proposal just works fine with [[Subversion]]'' too. You don't have to change your versioning system to improve your [[teamwork]].
		+
		+	[[Category:Video]]

---

Current revision

Mercurial (also known as Hg) is a distributed versioning system.

Question

There are a couple of guys in the team that I am currently working in who would like to switch from Subversion to Mercurial. Since you have been through that already, I was wondering if you could give me some feedback on how it went. Did the migration go well, did you have any major disruptions, ... ? Any practical hints are greatly appreciated.

Answer

I am really glad we switched to Hg. Distributed systems are really great. However the transition period was not easy. While Subversion is for clueless developers, in the Hg world people have to think. And that is slightly unnatural for some of these days programmers. One set of notes describing the issues can for example be found at Mercurial vs. Subversion page.

For a while people were complaining and making mistakes. But slowly most of them got over the problems and learned at least the basic commands to use Hg. At that time I decided to make them more effective and we implemented netbeans:HgParallelProjectIntegration.

This workflow really uses the power of distributed versioning system. You can have a pyramid of repositories and builders and on each level you can ensure the commit breaks nothing essential. Mistakes done by individual developers are isolated and make little harm (in contrast to previous model when each error means to everyone: "stop the world" and fix it). I am really proud of this workflow, but my co-workers hated me for at least six months. Of course, I was really bad, I forced them to think a bit about Hg, while they wanted to code.

These days the hate is mostly gone. Hg and parallel integration really makes us more productive. Once you get used to it, it is almost natural (throw some sarcastic comments in here). Definitely more natural than following practice of our new co-workers:

While I admire such cultural skills (I can't sing, I can just declaim), and maybe exactly because I sing horribly, my advice is clear: Use Hg! You will not have to learn to sing!

<comments/>

Side note

The netbeans:HgParallelProjectIntegration has been greatly inspired by a presentation by Koshuke about more distributed teamwork flow for Glassfish. The hierarchical delivery model fits naturally into distributed versioning system like Hg. However as Koshuke mentions at the end this proposal just works fine with Subversion too. You don't have to change your versioning system to improve your teamwork.