Version control for Linux (developerWorks) [LWN.net]

Version control for Linux (developerWorks)

Posted Oct 11, 2006 19:40 UTC (Wed) by felixfix (subscriber, #242)
In reply to: Version control for Linux (developerWorks) by JoeF
Parent article: Version control for Linux (developerWorks)

Noticed that. I wonder if there are, or ever have been, any version control systems which did not store deltas. Even old SCCS stored deltas. It seems a pretty pointless distinction to me.

Version control for Linux (developerWorks)

Posted Oct 11, 2006 19:56 UTC (Wed) by proski (guest, #104) [Link] (3 responses)

git doesn't store deltas by default. You have to run git-repack to create deltas.

This further indicates that the distinction between "snapshot model" and "changeset model" is artificial and useless. It also places CVS in the "snapshot model" category based on the server storage alone, while in fact CVS is unique among the currently used systems in NOT having any support for changesets spanning more than one file.

Version control for Linux (developerWorks)

Posted Oct 11, 2006 20:01 UTC (Wed) by proski (guest, #104) [Link] (2 responses)

I mean, it also places CVS in the "changeset model" category. The author had trouble applying his own definitions to CVS, and so did I :)

Version control for Linux (developerWorks)

Posted Oct 11, 2006 21:38 UTC (Wed) by JoeF (guest, #4486) [Link] (1 responses)

The changeset definition that the author uses, based on that the server stores deltas, is of course not how the SCM community defines it.
A changeset has nothing to do with how the servers store the data. It is an abstraction that specifies a collection of changes. CVS doesn't really use changesets, but Subversion does. I don't know enough about Arch to comment on its changeset use.

Version control for Linux (developerWorks)

Posted Oct 12, 2006 20:03 UTC (Thu) by njs (subscriber, #40338) [Link]

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.