Version control for Linux (developerWorks)

Version control for Linux (developerWorks)

To make it worse, most of the people _I_ know who actually work on SCMs prefer yet another definition again. The thing is, all the SCMs that anyone actually works on have whole-tree atomic commit as a matter of course, so it's pointless to talk about it. Also, traditional SCMs that use that terminology (perforce and bitkeeper in particular, I believe?) actually take both the "change" and "set" parts seriously -- because they are based on older systems that did commits per-file, they still have a concept of a single-file change, and then a changeset is a secondary structure that groups several such changes to together. In modern free SCMs, the whole concept of a single-file commit is just gone -- you have only one sort of change, and it is a change to the tree. So the term is misleading anyway.

OTOH, probably the single deepest divide between modern designs is between darcs on the one hand, and everyone else on the other. Darcs represents history as a set of equivalence-classes of tree changes, has basic operations like "commute", and is good at cherrypicking but not at referring to a particular tree state ("yesterday's build"). Other systems represent history as a DAG of tree changes (so still changes, but each change has a particular immutable location as well), have basic operations like "merge", and are bad at cherrypicking but excellent at referring to a particular tree state. Which of these works better, the relations between them, and so on, are active research topics, so it's useful to have a term to refer to the distinction, and people end up re-using the familiar words "changeset" vs. "snapshot"...

Life would be easier if this overloaded "changeset" term would just go away.