undefined | Better HN

0 pointsanton_gogolev12y ago0 comments

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

Now, if we look at Subversion, we see that given a particular revision there's no way to reliably determine its' "parent", because the fact that r6 is followed by r7 doesn't mean that changes in r7 were based off of r6.

If we look at any DVCS, each commit would have an explicit reference to its' parent(s), so there's always a non-ambiguous way to reconstruct the entire "chain" of relationships between commits.

0 comments

4 comments · 1 top-level

jlgreco12y ago· 3 in thread

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

tbrownaw12y ago

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.

anton_gogolevOP12y ago

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.

[1]: http://mercurial.selenic.com/wiki/Manifest

jlgreco12y ago

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

j / k navigate · click thread line to collapse