Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm looking for a filesystem (working through FUSE is fine) that keeps revisions of files (or anything else). It would conceptually resemble a revision control system like CVS, GIT, HG, SVN. But I don't want something that wraps a filesystem on top of one of these revision control systems. I'd rather it operate on top of a regular file tree.
The way I'm thinking about how I might do this if I were to implement it is this. It would be a reflective file system in that it's basis would not be a partition, but instead, would be a file tree on another filesystem. It would store things in that file tree however the design implements it. The stored files could be actual files that are presented, or delta files to save space when large files have small differences, or meta files to manage things.
The mounting of this file system would have at least two different modes:
1. A read-only access to any past revision. The mount would have to specify what revision to access, however revisions are identified. A variant of this mode would present all revisions under a top level pseudo-directory that has names for each revision.
2. A writable current mount mode. Changes made here would create new revisions.
One issue is when do writes and changes increment the version. I seriously doubt anyone wants a new version triggered when one block of a file gets updated. Even when a file being written or updated is closed would be excessive. The revision increment should be roughly equivalent to a complete check-in on a typical revision storage system. An unmount after any change should certainly be the minimum to increment the revision. But it might be desired to leave it mounted across an increment, so some means to force an increment would be good. Maybe "mount -o remount,revisionincrement=yes /mnt/revfs" would be good enough.
Note that this would not be a distributed revision control system. There would be no check-out (that can be changed and later checked back in). Maybe that could also be done, but I would see that as complicated beyond what I would need this kind of thing for. I don't want this as something to replace a revision control system.
Has anyone seen anything like this? Would it have any uses to anyone other than me? One use I'd put it to is as the target when I make backups of other systems via rsync.
I had not found that list. There are a couple that are potential candidates there. But they seem to handle accessing the old versions in an awkward way. Still worth investigating. NILFS also looks interesting, but being a core filesystem, it has the risk of development at that level. I want to use one that has its storage on an existing filesystem (either via FUSE or directly).