> This seems quite bad, but I have no idea how to fix it. Most people, when interacting with their database, use SQL (or whatever native command language it pr

> This seems quite bad, but I have no idea how to fix it. Most people, when interacting with their database, use SQL (or whatever native command language it provides), and don't need to worry about the underpinnings. Most people, when interacting with their source code repository tool, use the command set provided by the tool and don't worry about the underpinnings. I've had problems with my databases before that forced me to learn about the horrid can of worms underneath. Until I had these problems, I didn't care because it was entirely irrelevant to the thing I was trying to do. I've thankfully never had enough of a problem with any of the repo tools I've used (cvs, svn, hg, git) that I needed to go diving into the data structure itself to figure out or fix a problem. I hope I never have to, because that's not the job I'm trying to do. You shouldn't need to care how the tool works in order to use it, unless using it is your primary job. My primary job is writing code for my application, not writing code for my database or repo tool. If going distributed, hg provides a much more sane initial set of commands that make more sense to people with experience using anything that isn't git. This matters a lot, because those commands are the only things most users ever really care about.