4 ms·

> ...snapshot-based systems can be extremely fast, but require an in-depth knowledge of their internals This is false, as demonstrated by Mercurial.

testcross 11y ago
Can you give more details or a link about this please?
- gecko 11y ago
  I think he just means that, while many Git users may indeed be familiar with blobs, trees, commits, packs, refs, remote refs, and so on, most Mercurial users just know that they have changesets. Most Mercurial users do not know what filelogs are, how they work, what the manifest is, and so on. That said, I find the original claim, that users of snapshot systems have to know the internals, a bit idiotic. Subversion users definitely didn't, nor did most CVS users. Git seems to just be a very loud exception. Whether this is by necessity due to Git's UI, or whether it's simply that Git's data structures are more visible and discoverable, is a debate I'm not touching. (I'd note that there's a direct 1:1 correspondence for all core Git and Mercurial internal structures, so it's definitely not inherent in the snapshot model. There are even very nearly 1:1 analogs to older DVCSes, like BitKeeper and Monotone. Git users just tend to know more about the internals of their tooling.)
- IshKebab 11y ago
  Probably not but he is right - all the git tutorials inevitably lead to explaining how git works internally. It is considered necessary knowledge for "grokking" git. Mercurial tutorials aren't like that. It is a lot simpler to use so Mercurial tutorials tend to just tell you how to use it and don't mention the internel implementation details.
Grue3 11y ago
I dunno, Mercurial Queues are pure black magic that only the most advanced dark wizards can possibly understand.
- nsm 11y ago
  Please don't use mercurial queues. histedit, rebase and the recent changeset evolution extension allow you to do everything while having first class history and merging support. Also far easier to understand than git. Useful links (first 2 slightly Mozilla specific): http://ahal.ca/blog/2014/new-mercurial-workflow/ http://ahal.ca/blog/2014/new-mercurial-workflow/ http://ahal.ca/blog/2015/new-mercurial-workflow-part-2/ http://ahal.ca/blog/2015/new-mercurial-workflow-part-2/ http://evolution.experimentalworks.net/doc/ http://evolution.experimentalworks.net/doc/
- rbehrends 11y ago
  You're sort of making his point, since Mercurial Queues are about representing revisions as patches rather than snapshots. It's actually a pretty simple idea, just not how Mercurial normally works. That said, the problems with Mercurial Queues come from (1) a bolted-on command-line interface that doesn't fit in with the other hg commands and (2) poor integration with the rest of Mercurial. Which is why for most use cases evolve is considered the better option these days.

testcross 11y ago

Can you give more details or a link about this please?

gecko 11y ago
I think he just means that, while many Git users may indeed be familiar with blobs, trees, commits, packs, refs, remote refs, and so on, most Mercurial users just know that they have changesets. Most Mercurial users do not know what filelogs are, how they work, what the manifest is, and so on. That said, I find the original claim, that users of snapshot systems have to know the internals, a bit idiotic. Subversion users definitely didn't, nor did most CVS users. Git seems to just be a very loud exception. Whether this is by necessity due to Git's UI, or whether it's simply that Git's data structures are more visible and discoverable, is a debate I'm not touching. (I'd note that there's a direct 1:1 correspondence for all core Git and Mercurial internal structures, so it's definitely not inherent in the snapshot model. There are even very nearly 1:1 analogs to older DVCSes, like BitKeeper and Monotone. Git users just tend to know more about the internals of their tooling.)
IshKebab 11y ago
Probably not but he is right - all the git tutorials inevitably lead to explaining how git works internally. It is considered necessary knowledge for "grokking" git. Mercurial tutorials aren't like that. It is a lot simpler to use so Mercurial tutorials tend to just tell you how to use it and don't mention the internel implementation details.

Grue3 11y ago

I dunno, Mercurial Queues are pure black magic that only the most advanced dark wizards can possibly understand.

nsm 11y ago
Please don't use mercurial queues. histedit, rebase and the recent changeset evolution extension allow you to do everything while having first class history and merging support. Also far easier to understand than git. Useful links (first 2 slightly Mozilla specific): http://ahal.ca/blog/2014/new-mercurial-workflow/ http://ahal.ca/blog/2014/new-mercurial-workflow/ http://ahal.ca/blog/2015/new-mercurial-workflow-part-2/ http://ahal.ca/blog/2015/new-mercurial-workflow-part-2/ http://evolution.experimentalworks.net/doc/ http://evolution.experimentalworks.net/doc/
rbehrends 11y ago
You're sort of making his point, since Mercurial Queues are about representing revisions as patches rather than snapshots. It's actually a pretty simple idea, just not how Mercurial normally works. That said, the problems with Mercurial Queues come from (1) a bolted-on command-line interface that doesn't fit in with the other hg commands and (2) poor integration with the rest of Mercurial. Which is why for most use cases evolve is considered the better option these days.