2009/1/23 Norman Gray <[log in to unmask]>:
> 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.
That's like asking someone not to think of the colour green. Just
firing up youtube now...
David
|