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
|