Re:A book about Git, hosted on Github
by d0m on Monday August 02, 2010 @04:13PM
(#1568884)
I've read this book last summer to learn git and I pretty enjoyed it. Mainly because it's succinct and because the author does a wonderful job explaining why he really like git.
However, I don't get why it's on HN front page...?
Re:A book about Git, hosted on Github
by tzs on Monday August 02, 2010 @01:25PM
(#1568267)
That's a fairly nice book, but has a couple of errors. For example:
"The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes." ... "Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem."
I'd say he's got that completely wrong as far as Subversion goes. From a conceptual point of view, the easiest way to think of Subversion is in fact as a snapshotted file system. Here's how I used to explain Subversion to people when we moved from CVS to Subversion.
1. Think of it as a special filesystem. It's much like a Samba filesystem, in that it's stored on a server. However, instead of mounting it on your desktop, you access it through the svn command. You can copy stuff from it and to it.
2. What's special about it is that (a) changes are atomic, (b) copying is cheap in terms of time and space, and (c) special IT fairies watch over it, and whenever you make a change they first make a snapshot of the pre-changed filesystem. Most svn commands let you refer to those snapshots.
Sure, Subversion doesn't actually STORE the repository as some kind of snapshotting filesystem, but it makes it look like one as far as the user is concerned.
Re:A book about Git, hosted on Github
by tzs on Monday August 02, 2010 @06:22PM
(#1569330)
Yes, under the hood (although the distinction between file-based and content-based doesn't seem to be all the important from the conceptual model point of view--you generally access the content of blobs in Git via file-based interfaces).
The point is he's talking about how the systems appear conceptually. Conceptually the model that best describes Subversion from a user point of view is a file system that stores a snapshot of all prior states of the filesystem.
However, I don't get why it's on HN front page...?
An HTML version(ish) of the book
"The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes." ... "Git doesn’t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem."
I'd say he's got that completely wrong as far as Subversion goes. From a conceptual point of view, the easiest way to think of Subversion is in fact as a snapshotted file system. Here's how I used to explain Subversion to people when we moved from CVS to Subversion.
1. Think of it as a special filesystem. It's much like a Samba filesystem, in that it's stored on a server. However, instead of mounting it on your desktop, you access it through the svn command. You can copy stuff from it and to it.
2. What's special about it is that (a) changes are atomic, (b) copying is cheap in terms of time and space, and (c) special IT fairies watch over it, and whenever you make a change they first make a snapshot of the pre-changed filesystem. Most svn commands let you refer to those snapshots.
Sure, Subversion doesn't actually STORE the repository as some kind of snapshotting filesystem, but it makes it look like one as far as the user is concerned.
This is what Linus refer to as a "stupid content tracker" because Git tracks content changes not file changes.
Git: content-based, snapshot-storage
The systems are completely different.
The point is he's talking about how the systems appear conceptually. Conceptually the model that best describes Subversion from a user point of view is a file system that stores a snapshot of all prior states of the filesystem.