Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've done some work looking at Next3 and ext3cow, and a few other file systems that provide snapshots and/or file versioning. It seems a bit strange to me that file systems only go part-way with version control, though.

Are there fundamental reasons for keeping the two separate? How challenging would it be to, for example, build a version of the ext3 file system which includes a git-like interface for managing file versions?

share|improve this question
A file system which includes versioning? you mean like git? Someone correct me if I'm wrong, I'm not a git guru, but to my knowledge what your describing is exactly what git IS. Applicable quote: "In many ways you can just see git as a filesystem — it's content-addressable, and it has a notion of versioning, but I really really designed it coming at the problem from the viewpoint of a filesystem person (hey, kernels is what I do), and I actually have absolutely zero interest in creating a traditional SCM system." – Brook Sep 14 '11 at 0:33
@Brook: I believe the OP is asking why version control isn't natively part of file systems. – Demian Brecht Sep 14 '11 at 0:37
@Demian Brecht:You're right, I was addressing more the "how challenging would it be" part. It would be roughly about as challenging as implementing git. eg, pretty darn challenging, at least for a relative simpleton such as myself. – Brook Sep 14 '11 at 0:44
I'd like to point out that there is middle ground between "VCS on top of FS" and "FS versions everything". For example, you could have a FS where an attribute on a directory enables version control. – detly Sep 14 '11 at 3:53

2 Answers 2

up vote 7 down vote accepted

The fundamental reason is people don't want to create a new version every time they save their files. If you've ever worked on a system like VAX/VMS that creates a new version every time you save, you'd know how annoying it can get. Your disk fills up quickly, and you only have version numbers to go off of if you want an older version, no useful commit messages. The killer feature of version control software is to be able to choose when not to commit.

share|improve this answer
+1. The answer to almost all "Why don't we do it this way?" type of questions is "Because we already tried it in the 60s and it didn't work!" – Jörg W Mittag Sep 14 '11 at 1:36
It was rumored that ODS-2 (the original VMS filesystem) had version numbers so as to allow DEC to sell more disks. – Bruce Ediger Sep 14 '11 at 2:14

Sure- consider the size. I've got 850GB sitting on my harddrive, used, with 70GB left. How precisely do you plan on versioning any of that content? I would need a truly insane amount of space to version that.

Source control is only really useful for that- source. Because much else is just too big to keep around redundant copies of. Source is nice and small and frequently modified. My 150GB of Stargate, however, is massive and will never be altered. I certainly wouldn't want it to be versioned.

share|improve this answer
If it's not going to be altered, then there will only ever be one version, and that version will double as a backup, no? – blueberryfields Sep 14 '11 at 1:09
@blueberryfields: You can't back up a file with itself. That's not a backup. – DeadMG Sep 14 '11 at 8:00
I made the assumption that you're versioning it and storing it in a repository somewhere. Is the overhead of adding versions to files so significant, in the absence of also storing copies of them in a repository? – blueberryfields Sep 14 '11 at 15:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.