 |
 |
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