> Let's define "revision" to be "what the entire codebase looked like at some particular point in time" and "changeset" to be "a list of changes between one specific revision and the next specific revision".
Git tracks revisions then. Commits have a tree object that describes the codebase at the time of the creation of the commit. You don't need to transverse any previous commits to recreate that tree. Commits also have other commits objects listed as their parent commits, but they are not needed to examine the current state.
Git doesn't use deltas in the way that Mercurial does.
The only system I know of that truly tracks changesets rather than revisions is Darcs.
But from a more practical standpoint, tracking changesets rather than just revisions means recording ancestry ("commits also have other commits objects listed as their parent commits") such that you can freely create merge revisions and the system will Do The Right Thing with minimal hand-holding.
The internal repository format isn't really relevant here, it's about the way of thinking that the system is designed to support.
Mercurial storing deltas is just an optimization (sometimes it stores full snapshots): all manifests [1] refer to full file content, not deltas.
Let's put it this way: the key feature of DVCSes is that they store explicit relationships between a particular commit and its parents. This makes it trivial to reconstruct actual changesets as per my definition, which in turn makes merge machinery much more reliable.
Okay, that I can agree with. I just think it is misleading to say they are based on change lists since changelists can be derived but are not actually stored. (And in the case of git at least, the changes you derive may not be changes that a human made, per se (in other words, those changes are the output of rebase.))
Git tracks revisions then. Commits have a tree object that describes the codebase at the time of the creation of the commit. You don't need to transverse any previous commits to recreate that tree. Commits also have other commits objects listed as their parent commits, but they are not needed to examine the current state.
Git doesn't use deltas in the way that Mercurial does.