I definitely didn’t want to say I dislike Hg. I’m just using Hg a lot recently and listed things that I encountered that were a problem for me. Main reason was hope that people will point out solutions

So Dirkjan, fear not I love Hg and find it extremely useful and a huge upgrade not only for work on basic products, but a great stimulation for easy forking, and branching, and experiments. Its just that writing what’s GOOD about Hg to people who’re using it every day is not that big topic

No problem. Lets try to change the last part here (“aa3c4d3fb3fc”):

http://hg.mozilla.org/users/zbraniecki_mozilla.com/silme/file/aa3c4d3fb3fc

to: “multilocale”, “trunk” or “tip” -> it works

First off, we know that something like svn:externals would be good, but this is certainly not a trivial thing to accomplish. I can happily say that someone is currently working on a new extension that we may be able to integrate as soon as it gets good enough.

As for cloning specific directories, this stuff doesn’t always make sense in a DVCS. For example, how will you merge two heads that have disparate changes outside the cloned directory? Having said that, we have some code working towards this and are certainly aware of the feature (we call it ‘narrow cloning’, as opposed to ‘shallow cloning’, which means pulling down only a recent part of the history.

I’d suggest the separate commit to merge is anything but a dirty hack. I’d say anything else would be a crutch. I’d encourage to play with hg more. Besides, I think git and bzr do the same thing here.

Of course, I especially care about your hgweb concerns. First off, the links that you describe are actually possible, I think. URLs for hgweb are made up of //. If you link to file//some/dir that should get you a directory listing for that revision. Use ‘tip’ for if you want to link to the latest version.

I have actually been moving the code to where it is easy to arbitrary diffs. Biggest holdup there is a good UI, which is not usually my strong suit. The revision numbers, if you want them, could probably be made available from the templates; since Mozilla uses their own templates, file a bug with mozilla in the HG :: Customizations component and it can get fixed fairly soon. Similarly, your workflow problem sounds like a templates problem (or maybe you’re clicking the wrong link).

The summary, too, is a feature of the templates. We think the summary is not ideal, and don’t use it in our most recent template sets.

Finally, I beg you to actually come into our community (bug tracker, IRC: #mercurial on freenode) and ask about your issues. Chances are some of them can get fixed soonish, others can be put on the agenda. Also, it would be in hg’s best interest (which I think in some ways would also be of interest of Mozilla) if there also came some positive notes about hg into the Mozilla community. While a lot of people actually like hg from what I’ve seen, the atmosphere around it is kind of negative, which is too bad. I really don’t think other DVCSs would do better on most of your counts (they would probably have many similar constraints and a bunch more nags that we don’t have).

Been using git on Windows, too… Seems pretty nice, so far, feels more mature than hg, with some different architecture (doesn’t assume commit all changes, for one). Last I checked though, git-svn was too slow to be useful there.

Re: hg.m.o links: http://hg.mozilla.org/mozilla-central/file/tip/configure.in

I also wish for partial pulls; in fact, I want to be able to forget old history too. (I don’t care about things older than a month; I can look at the upstream repo for that if necessary…)

Don’t know if this is a right solution?
For ex, instead of:
http://hg.mozilla.org/mozilla-central/file/8dcbd3d42d68/README.txt
we’ll use:
http://hg.mozilla.org/mozilla-central/file/tip/README.txt

And what SVN is doing in such case? It just removes the file from it. I don’t see it as a problem.