I didn't notice the date on the answer. Someone with StackOverflow edit powers really ought to go back and update the response. It's nice to see that Mercurial

I didn't notice the date on the answer. Someone with StackOverflow edit powers really ought to go back and update the response. It's nice to see that Mercurial is integrating these things into the core. My experience with Hg was over 3 years ago, before this answer was written. RE: acl -- I understand it. I just don't really see a need for it because I prefer pull-requests and decentralized decision making. I truly dislike the "commit bit" culture that accompanies centralized repositories and acls seems to import some of that culture. I'm a big believer in better to beg for forgiveness than to ask for permission, and therefore I'd much rather say "Hey, I changed these files, you should pull from me" and if I fucked up, you can call me an idiot and I'll have learned something. Maybe put a README in the special directories! Then again, I feel similarly about method access control in C++ & Java vs Python. Python's underscore prefix for private bits is enough to stop me from screwing up, even though I can dig in and fiddle with private stuff if I actually know what I'm doing and no compiler is going to stop me. > most users shouldn't be touching them Mercurial is clearly designed for easy of learning. That's a worthwhile goal, and I think that it's great at that. As I mentioned, I started with Mercurial. It's a great offramp from SVN and onramp to DVCS. However, my version control system gets more use than any software on my system, minus my text editor! It's worth learning. It's worth investing in. And it's worth having a sub-par beginner experience to optimize for the experts.... for me. I'd recommend Hg to any team looking to get started with DVCS where there is a mix of stronger and weaker devs and you're sure to have people who are going to have difficulty understanding Git. Hg is easy enough for beginners and flexible enough for experts. Git, however, is tuned for experts. I know quite a few people who have worked with both, and they all prefer Git... in time.