6

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?

Improve this question
4
  • 1
    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, 2011 at 0:33
  • @Brook: I believe the OP is asking why version control isn't natively part of file systems.
    – Demian Brecht
    Sep 14, 2011 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, 2011 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, 2011 at 3:53

2 Answers 2

Reset to default
7

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.

Improve this answer
2
  • 6
    +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, 2011 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, 2011 at 2:14
4

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.

Improve this answer
3
  • 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, 2011 at 1:09
  • @blueberryfields: You can't back up a file with itself. That's not a backup.
    – DeadMG
    Sep 14, 2011 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, 2011 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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