4 ms·
> The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a
by avgcorrection 3y ago
> The only thing I'd really adjust in that statement is condensing down the description of trees to "commits are a snapshot of the repository" (as opposed to a diff, which a lot of people seem to think commits are despite it being a niche model in VCS design).
A lot of VCS have used diffs to implement commits. But... they have also used snapshots from time to (every N commits) in order to make checking out old commits more efficient. Apparently this is how Mercurial works and how either Subversion or CVS implements it.
This is based on some article I read yesterday. I could dig it up if this turns out to be wrong.
- rcxdude 3y agoNow that is an implementation detail: all of those tools treat commits as snapshots primarily. Internally they may use diffs in order to compress the data (as does git), but the commits are primarily presented to the user as snapshots, and only secondarily treated as diffs in some circumstances (this flipping is a confusing point, to be fair, and something which git does a lot more of, which I think can add to the confusion. e.g. rebases are really turnings a series of commits into diffs, and then applying those diffs onto a different base commit to create a new string of commits. But the git man page just describes this as 'moving commits'. SVN and CVS just don't support this functionality, and mecurial buries it behind an extension). If you want examples of VCS that treat commits as diffs conceptually, look at darcs and pijul.
- avgcorrection 3y agoGood point about patch-based VCSs. The diff/snapshot thing is definitely an implementation detail for snapshot-based VCS. (I haven't tried out patch-based ones yet.)