>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. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
