Fwd: [admin] Decentralized versioning system at W3C; Git vs. Mercurial

Comments from Josh Soref.

Begin forwarded message:

> From: Soref Josh
> Date: December 22, 2009 4:39:32 AM EST
>
> The reason I didn't really want to write on this subject is that  
> I'm obviously biased, I've ended up writing a bunch of fixes for Hg.
> In my defense, I'm not a Python coder, and I try very hard to  
> retain this assertion, and yet, I haven't had trouble making  
> improvements or fixes to Hg's code even while insisting that I'm  
> not a Python coder (Bonsai is Perl).
>
> OTOH, I've also written changes for CVSNT (I don't remember what  
> happened to them, but I have), and I've poked around Bazaar and  
> Git, and I've toyed with Darcs.
>
> So, I've tried to use Git at times, and I've found its UI,  
> documentation and help to be really awful. I've also tried writing  
> patches to improve stuff (including but not limited to the  
> documentation), and I've given up.
>
> As for tools, Google supports Hg with some of their tools, and I've  
> adapted bonsai to support it. I'm aware there are a number of tools  
> for Git, but I haven't found any of them which are unique to Git  
> compelling. The most commonly mentioned tools are basic web guis  
> and those are generally made available for all DVCSs.
>
> http://mxr-test.konigsberg.mozilla.org/html5/source/source
> is an Hg managed convert of hixie's Subversion because Subversion  
> irritates me so much that I've found I much prefer to not use it at  
> all (and I've spent years trying to work with Subversion and seen  
> other people give up integrating with it [although this is perhaps  
> limited to bonsai-svn integrators]).
>
> The bonsai Hg links from that page should work, and lead to:
> http://mxr-test.konigsberg.mozilla.org/bonsai/cvslog.cgi?file=/ 
> source&mark=de56a3872f2e&tree=html5
> and a similar page for blame, although that seems to time out :(
> http://mxr-test.konigsberg.mozilla.org/bonsai/cvsblame.cgi?file=/ 
> source&rev=100&tree=html5 is a simplified example
> http://mxr-test.konigsberg.mozilla.org/bonsai/cvsblame.cgi?file=/ 
> source&rev=1000&tree=html5 takes longer (i'm going to actually  
> profile this case because it feels like things get too slow as the  
> revision count grows, and the profiling tools for Hg are really  
> easy to play with)
>
> In Nokia's Maemo Devices group, we have a tools team which does  
> work for Git and Hg. The teams dependent on Git are constantly  
> complaining about problems with the Git gateways and syncing stuff.  
> Git supports a couple of protocols, Git over ssh and http, it seems  
> that the http transport is incredibly slow, so any time someone  
> makes the innocent mistake of entering an http url into the tools  
> we use, the system takes ages and gives no useful feedback. It's  
> possible that the people writing our Git tools aren't intelligent,  
> but I don't think that's the case - I don't think this is their  
> fault, I believe they're smart people and are doing their best.
>
> In contrast, Mercurial over https seems to work fine.
>
> To be fair, more teams in Maemo Devices use Git than Hg, but the  
> problem isn't really the quantity of repositories (although it  
> certainly doesn't help matters), any individual repository seems to  
> be able to cause significant pain. Part of this of course is  
> because we live behind a moat -- if w3 doesn't have a moat then  
> some of the pain we experience wouldn't apply.
>
> In general, DVCSs are roughly equivalent, although the command  
> names for Git are less intuitive IME (I'm pretty sure I tried using  
> Git a couple of times with a number of projects before I used Hg).  
> Each time I go to use Git, I have to search for an explanation or  
> tutorial, and from memory I can't simply pick the first hit,  
> because well, there are a number of places with text, but a lot of  
> it is poor.
>
> In the end whether one picks Git or Hg, people will survive. And as  
> I haven't done much in the way of spec editing, my input isn't  
> really that important.
>
> http://versioncontrolblog.com/comparison/Git/Mercurial/Subversion/ 
> index.html came up in a random search for gitweb - it's dated 2008,  
> so it's technically perhaps 2 years old, however I don't believe  
> much of the data contained within is particularly inaccurate or out  
> of date (yes, there's now  a non Cygwin port of Git for Windows).
>
> This letter obviously does not represent Nokia's official views,  
> nor that of Maemo Devices or any other organization with which I  
> have any involvement. (I've also worked with Netbeans and  
> OpenSolaris, both of which through no involvement of mine happened  
> to pick Hg and both of which seem happy with it:
> http://netbeans.dzone.com/articles/switching-mercurial
> http://hub.opensolaris.org/bin/view/Community+Group+tools/ 
> dcm_evaluation_mercurial (this was probably the initial evaluation,  
> the bug about merging linked by it is resolved)
> -- OpenSolaris has a fairly structured analysis process, I think  
> the entry point was roughly:
> http://hub.opensolaris.org/bin/view/Community+Group+tools/evalform
> the final write links are here:
> http://hub.opensolaris.org/bin/view/Community+Group+tools/history
>
> It's true that I was involved in helping them evaluate Bugzilla  
> (which they eventually used), but I don't think that makes me  
> biased :).
>
> Perhaps a real oddity, Symbian chose Mercurial:
> http://developer.symbian.org/wiki/index.php/Mercurial_Q&As
> On that note, http://victorpalau.wordpress.com/2009/07/31/even-i- 
> can-use-mercurial/ is amusing
>
> And yes, I'm well aware that Qt picked Git, and Qt + Maemo have  
> spent money to try to make *.gitortious.org useful, I've found it  
> so bad that my solution has been to spend time working with Ohloh  
> (ohloh.net) to improve its knowledge of them so that I can use it  
> instead, and it isn't designed to be a UI for *VCSs!

Received on Tuesday, 22 December 2009 18:12:53 UTC