Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Versioning File Systems




---- Original message ----
>Date: Mon, 07 May 2012 07:48:37 -0400
>From: discuss-bounces+j.natowitz=rcn.com at blu.org (on behalf of David Kramer <david at thekramers.net>)
>Subject: Re: [Discuss] Versioning File Systems  
>To: discuss at blu.org
>
>On 05/05/2012 03:13 PM, MBR wrote:
>> On 5/4/2012 7:13 PM, Richard Pieri wrote:
>>> Versioning isn't revision control. Revision control isn't versioning.
>>> There is some overlap in what they do but they aren't the same thing.
>>> --Rich P. 
>> That's becoming clear.  I'm trying to understand the difference.  It
>> seems like versioning is having the operating system do for all files
>> what emacs does for text files.  Is it that versioning automatically
>> provides me with some number of backup copies of the file that I can go
>> back to in case I screw something up, as long as I don't mistakenly
>> delete the whole file.  And that's contrasted with revision control
>> which is not automatic.  It requires a conscious decision to save a
>> version, but can track file deletion and renaming, and knows about sets
>> of file revisions that produce a working system.  Do I have that right?
>
>In the context of software development, it is much more important to
>have a snapshot of ALL FILES at any point in time than one particular
>file, since they depend on each other so heavily.  Versioning
>filesystems won't do that.

So in essence, you want a filesystem that does the equivalent of taking a snapshot every time the filesystem changes.  I don't know of any that currently do that.   It could be done, there would be a lot of storage overhead for all the file revisions.  Normal operations wouldn't be affected too much due to caching, but views of the system in the past would have a rather high cost.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org