3 ms·

I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially

I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.) This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.

kyrra 12y ago
Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays. [0] http://mercurial.selenic.com/wiki/RevlogNG http://mercurial.selenic.com/wiki/RevlogNG [1] http://ericsink.com/vcbe/html/repository_structure.html http://ericsink.com/vcbe/html/repository_structure.html EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog/ http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...
rkangel 12y ago
The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach. The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools. There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability. How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.
McGlockenshire 12y ago
> 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.
pnathan 12y ago
hg has a very elegant underlying data model, which you wind up not having to care about at all (a nice property of a good abstraction), unlike git. :) I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.

kyrra 12y ago

Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays. [0] http://mercurial.selenic.com/wiki/RevlogNG http://mercurial.selenic.com/wiki/RevlogNG [1] http://ericsink.com/vcbe/html/repository_structure.html http://ericsink.com/vcbe/html/repository_structure.html EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog/ http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...

rkangel 12y ago

The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach. The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools. There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability. How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.

McGlockenshire 12y ago

> 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.

pnathan 12y ago

hg has a very elegant underlying data model, which you wind up not having to care about at all (a nice property of a good abstraction), unlike git. :) I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.