Re: versioning file system
On 10/26/18 6:57 AM, Dan Ritter wrote:
On Thu, Oct 25, 2018 at 05:32:52PM -0700, David Christensen wrote:
I did Fortran programming on VAX/VMS machines back in the 1980's. Its
file versioning feature was a godsend [1][2]. I want that on my Debian
machines.
2018-10-25 17:28:29 dpchrist@vstretch ~
$ apt-cache search versioning file system
copyfs - Versioning filesystem for FUSE
davfs2 - mount a WebDAV resource as a regular file system
dvcs-autosync - Automatically synchronize distributed version control
repositories
fsvs - Full system versioning with metadata support
fusedav - filesystem to mount WebDAV shares
incron - cron-like daemon which handles filesystem events
python-migrate - Database schema migration for SQLAlchemy - Python 2.7
python-migrate-doc - Database schema migration for SQLAlchemy - doc
python3-migrate - Database schema migration for SQLAlchemy - Python 3.x
Has anybody tried copyfs, fsvs, or anything else with file versioning?
The problem with fsvs and copyfs and other FUSE-based things is
that they tend to be slow, so slow that you don't want to put
major chunks of your system in them.
Yes, FUSE is slower. But, it might be fast enough for what I have in mind.
On the other hand, it's usually easy to make whatever editor you
habitually use hook into a versioning system for every save:
emacs git-auto-commit-mode
vim vim-auto-commit or fugitive
atom Git-Plus
When I'm working on a file, I can do ten edit/ saves, or more. With a
versioning file system, the original file plus all the saves would be on
disk. This makes it easy to pick through them using standard tools.
But if the original file and all but the last save are in a version
control system (VCS), I would need tools that can reach inside the VCS.
Searching the manual pages of cat(1), grep(1), diff(1), and make(1) for
'CVS' just now, I found zero hits. This means I'd need to check them
out. Now I'm back to what a versioning file system gives me automatically.
Furthermore, auto-commit on every save would put a lot of cruft into the
VCS, to be stored, backed up, and archived repeatedly and indefinitely.
If I try to remove the VCS auto-commits by hand, eventually I will
damage or destroy the VCS repository (e.g. Murphy's Law). Removing VCS
auto-commits mechanically would require developing and validating a
suitable work flow and tools, adding cost and limiting flexibility.
and it turns out that Microsoft open-sourced Visual Studio Code
and it has git support built-in.
On the other hand, if you want a system that is fast and can
handle everything, not just what you are working on right now,
you could
- install rsnapshot and have it do automatic periodic backups,
like once an hour
- use ZFS and tell it automatically make snapshots, maybe even
once an hour (syncoid/sanoid are your friends here).
Copy-on-schedule solutions have their cost/ benefit propositions. But
for this use-case, I want a copy-on-write solution.
David
Reply to: