[lkml]   [2007]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Versioning file system
Bryan Henderson wrote:
>> Part of the problem is that "whenever you modify a file"
>> is ill-defined, or rather, if you were to take the literal meaning of it
>> you'd end up with an unmanageable number of revisions.
> Let me expand on that. Do you want to save a revision every time the user
> types in an editor? Every time he runs a "save" command? Every time a
> program does a write() system call? Every time a program closes a
> modified file? If you're adding to a C program, is every draft you
> compile a revision, or just the final modification after the bugs are
> worked out?
> When I was very new to coding, I used VMS and thought the automatic
> revisioning would be a great thing because it would save me when I
> modified a program and later regretted it. The system made a revision
> every time I exited the editor. But I soon found that the "previous
> revision" to which I wanted to revert was always many editings back, since
> I spent a lot of time trying to make the regrettable code work before
> giving up. VMS kept a fixed number of revisions per file. But keeping 20
> versions of other files would have been wasteful of disk space, directory
> listing space, etc.
> Later, I discovered what I think are superior alternatives: RCS-style
> version management on top of the filesystem, and automatic versioning
> based on time instead of count of "modifications." For example, make a
> copy of every changed file every hour and keep it for a day and keep one
> of those for a week, and keep one of those for a month, etc. This works
> even without snapshot technology and even without sub-file deltas. But of
> course, it's better with those.

From what I can see this seems to be the consesus (and it sound very
sensible to me).

The question remains is where to implement versioning: directly in
individual filesystems or in the vfs code so all filesystems can use it?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-06-18 18:41    [W:0.075 / U:2.728 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site