The permalink appears to be http://blog.mozilla.com/blassey/2008/02/05/hg-as-a-colaboration-tool/ .

Thanks for your time. Hope this is of some use, interest.

Joseph

PS: IMO, the little GUI icons beside the fields for posting a comment should have a tooltip or something, and/or a text addition, indicating what each field is supposed to contain. I had to look at the file properties for each graphic and look at the file name to make a guess as to what’s supposed to go where. — J

dougt makes the point that you can even do cloning-like things with CVS: because it’s simple and you’ve used it for years and you understand it, you can hack it (writing shell scripts to copy things around and make patches, for example.) And because you write the hacks yourself, they’re no more complex than your use case demands, and you understand them and are less likely to make mistakes.

(I kind of disagree with all that, but I can see where he’s coming from.)

The power of hg is all in cloning. Where with CVS there’s a single central repo, hg gives you an arbitrary graph of repos that you can hook up any way you want.

The power is in the paradigm shift, and the paradigm shift is tricky and takes time to absorb. Hence my comparison to C vs. C++.

(for full disclosure, I haven’t had to touch it for actual development yet)

Now it seems that it was a misconfigured merge tool….

I had the exact problem, see my “PS:” part on his blog comment….

I wouldn’t presume to tell Brad or you what you should be doing instead of your current practices, because as far as I know, you haven’t said what those practices are.

In particular, if you are having problems and you’re not reporting them to the Mercurial developers, then they can’t help.

The power of a distributed SCM (like Mercurial or git) isn’t in the commands but how you can work in an isolated and local environment until you are ready to push your changes to a more public location.

Learning the commands is separate.

-kto