Folks,

I feel pretty diffident chiming in in a discussion which doesn't  
directly affect me, and in any case most of what I would say has been  
said by others here.  The following are therefore fairly disconnected  
observations, connected with one or other message in this thread, and  
not meant to persuade one way or another.



I now use hg repositories for code and text that I don't intend to  
share, but do want to snapshot regularly: it means I can note in my  
logbook that 'version X does actually work', and be able to  
reconstruct that fairly painlessly.

It struck me that DVCS systems represent an alternative evolution of  
RCS.  CVS and SVN developed RCS by allowing multiple users to access  
the same RCS repository (literally in early CVS, but with the same  
model in SVN).  DVCS takes the alternative route of going back to the  
RCS model of private repositories, but making it easier for different  
such repositories to be synchronised.  I suspect that this is, in  
retrospect, a better overall evolution of RCS.

The cost, as others have noted, is that there isn't some master  
repository for the code as there is for CVS and SVN.  I get round that  
by having my private hg repositories be clones of repositories on a  
group server which is carefully backed up by others, but there are  
clearly other ways this can be handled, which don't necessarily have  
to involve more elaborate laptop backups.

I like being able to make frequent commits of code which is working,  
but still isn't in a state I'd much want anyone else to look at.  I  
don't myself feel this is a particularly strong point, but this does  
usefully emphasise that committing != sharing, necessarily.

I'm not an enthusiastic brancher (though I admit I may well be missing  
a trick here), so can't add anything there.

In the project where we were forced to use hg (or git) we've ended up  
imitating the structure of a SVN repository, more or less, in the  
sense that there's effectively a master repository and checkouts (all  
hg clones are equal, but some are more equal than others).  This may  
or may not be missing the point, but if nothing else indicates that hg  
is potentially a better svn than svn.

I do occasionally find hg histories a bit confusing.  The fact that  
there isn't a single master repository means that you do end up  
merging more often, since updating after someone else has pushed to  
the 'main' repository means that, logically, you have to merge their  
changes into your (local) repository.  That has worked completely  
painlessly so far, and the increased amount of merging is simply an  
innocuous consequence of the different logic of a DVCS (I think my  
nervousness was because merging operations in CVS/SVN were usually  
associated with pain of some sort or other), but I have occasionally  
had puzzles of the 'why am I being asked to merge this?' variety,  
which probaby arise from naivety on my part.

In that sort of context, remarks like Tim's "(although you would  
"rebase" before merging to master to linearise the commit history)"  
just make git smell even more confusing, for me.  The fact that Tim's  
URL <http://www.gnome.org/~newren/eg/> lists _several_ attempts to  
provide easy wrappers for git just confirms all my impressions of git  
(though I do confess that I haven't been systematic about looking at  
git vs hg, so this is just at the level of impressions).  I do try  
hard not to be influenced by the git name, nor by Torvalds' efforts at  
promoting it -- never watch his Google tech talk on git.

The git cheat-sheet is at <http://git.or.cz/gitwiki/GitCheatSheet>,  
the Mercurial one (which the Git one imitates) is at <http://www.ivy.fr/mercurial/ref/v1.0/Mercurial-Usage-v1.0.pdf 
 >.

See you,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester