Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201653 > unrolled thread

versioning file system

Back to article view | Back to linux.debian.user

Contents

  versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-26 02:40 +0200
    Re: versioning file system Roberto C. Sánchez <roberto@debian.org> - 2018-10-26 04:50 +0200
      Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-26 22:20 +0200
    Re: versioning file system songbird <songbird@anthive.com> - 2018-10-26 05:10 +0200
      Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-26 22:10 +0200
        Re: versioning file system Erik Christiansen <dvalin@internode.on.net> - 2018-10-29 06:50 +0100
          Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-29 08:00 +0100
      Re: versioning file system Jonathan Dowland <jmtd@debian.org> - 2018-10-26 22:10 +0200
    Re: versioning file system Dan Ritter <dsr@randomstring.org> - 2018-10-26 16:00 +0200
      Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-26 23:30 +0200
        Re: versioning file system David <bouncingcats@gmail.com> - 2018-10-27 00:30 +0200
          Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-27 02:30 +0200
    Re: versioning file system Jonathan Dowland <jmtd@debian.org> - 2018-10-26 22:10 +0200
      Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-26 23:50 +0200
        Re: versioning file system Jonathan Dowland <jmtd@debian.org> - 2018-10-28 15:50 +0100
          Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-29 04:00 +0100
            Re: versioning file system Jonathan Dowland <jmtd@debian.org> - 2018-10-30 10:50 +0100
              Re: versioning file system Michael Stone <mstone@debian.org> - 2018-10-30 11:50 +0100
                Re: versioning file system David Christensen <dpchrist@holgerdanske.com> - 2018-10-30 19:10 +0100

#201653 — versioning file system

On 10/25/18 8:59 AM, songbird wrote:
> i'm sometimes developing code and in the process manage to mess it up
> where it isn't backed up or in any other spot, but i do have this 
> habit of keeping a terminal open with text and i sometimes cat or 
> scroll files there so as long as i don't shut down the system i can 
> go there and cut and paste things.
> 
> today this saved me a mild panic as i'd written some code and then 
> thought i'd copied it, but then i'd clobbered that copy doing 
> something else.
> 
> *whew*
> 
> and yes, i do make backups here or there, but sometimes i work
> faster than i do that.  i also use git, but i don't always stash
> temporary copies all the time.  today i actually did make a temporary
> copy, but that copy i clobbered on purpose and then said "oops"  :)
> 
> i started looking at undelete file utilities and then said, hey 
> perhaps i have this scrolled in another terminal...
> 
> now the really nice feature would be if i actually made this into a 
> system where my vi editor would automagically scroll it for me in 
> some window... that will be for some other time.  i don't want to
> get sidetracked any more for the moment.  gardens are sidetracking
> me enough...
> 
> just some thoughts in passing.  :)


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:27:39 dpchrist@vstretch ~
$ cat /etc/debian_version
9.5

2018-10-25 17:28:26 dpchrist@vstretch ~
$ uname -a
Linux vstretch 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08)
x86_64 GNU/Linux

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?


David


[1] https://en.wikipedia.org/wiki/Files-11

[2] https://en.wikipedia.org/wiki/Versioning_file_system

[toc] | [next] | [standalone]

#201654

On Thu, Oct 25, 2018 at 05:32:52PM -0700, David Christensen wrote:
> 
> Has anybody tried copyfs, fsvs, or anything else with file versioning?
> 
In my experience, I have only found a need to version /etc and $HOME
(and really only parts of $HOME, as opposed to all of it).

I find that git works really well for that.  In particular, on Debian
you can install etckeeper and it will automatically commit any changes
to /etc before a package installation run, after a package installation
run, and on a daily basis.  You can also manually commit and customize
the message.

More than that might be overkill and/or more trouble than it is worth.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#201716

On 10/25/18 7:45 PM, Roberto C. Sánchez wrote:
> On Thu, Oct 25, 2018 at 05:32:52PM -0700, David Christensen wrote:
>>
>> Has anybody tried copyfs, fsvs, or anything else with file versioning?
>>
> In my experience, I have only found a need to version /etc and $HOME
> (and really only parts of $HOME, as opposed to all of it).

/etc, per-user development directories, and per-user document 
directories are what I have in mind.


> I find that git works really well for that.  In particular, on Debian
> you can install etckeeper and it will automatically commit any changes
> to /etc before a package installation run, after a package installation
> run, and on a daily basis.  You can also manually commit and customize
> the message.

I've noticed etckeeper over the years, but have yet to try it.  I didn't 
know it integrated with Apt; this supports my implied goal of copy-on-write.


David

[toc] | [prev] | [next] | [standalone]

#201656

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

...

  what i really need to do is trust and use git 
commits more but i have a block about some 
things...  *sigh*


  songbird

[toc] | [prev] | [next] | [standalone]

#201710

On 10/25/18 7:33 PM, songbird wrote:
> 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
> 
> ...
> 
>    what i really need to do is trust and use git
> commits more but i have a block about some
> things...  *sigh*

When programming, I tend to do check-in's when I make some kind of 
progress (ideally, the code builds and the test suite passes).


The trap is when I work for a while, make some progress, make a wrong 
turn, and then make a mess.  A versioning file system makes it easy to 
get back to "make some progress" and try a different turn.


The compromise is to do a "work in progress" check-in prior to risky turns.


David

[toc] | [prev] | [next] | [standalone]

#201828

On 26.10.18 13:05, David Christensen wrote:
> When programming, I tend to do check-in's when I make some kind of progress
> (ideally, the code builds and the test suite passes).

Yup, the smaller edits of bugfixes aren't going to threaten code stability.

> 
> The trap is when I work for a while, make some progress, make a wrong turn,
> and then make a mess.  A versioning file system makes it easy to get back to
> "make some progress" and try a different turn.

Yes. If the major hack can be limited to one file, I've been known to
rely on Vim's undo capability to buffer all the changes long enough for a
build and test. That could perhaps be extended to several editor
instances for a couple of files, for a quick but disruptive tentative
test of a divergent approach.

The more robust way is though to develop on a VCS branch, check in prior
to jumping off the cliff, and merge back to trunk when it's all sorted
and tested.

> 
> The compromise is to do a "work in progress" check-in prior to risky turns.

Yup, but risk can grow after initial edits reveal that additional
structural changes are needed in order to enable the revised strategy to
be completely implemented. In response to that late awareness, I've been
known to ifdef out the old, to leave it in the file for recovery if a
massive stone ball comes rolling down the path I've hacked through the
jungle.

And yes, if CVS is the VCS you're most familiar with, then it's still
fit for use. Traffic on the ML is rare now, but there is still some
legacy use out there, and I use nothing else for my own versioning,
having used it for multi-team international software development for
many years. Its automatic merging capability alone is a dream.

OK, git is quicker and preferred for big projects, but for small teams
of greybeards who were weaned on it, CVS is still fine. (And if you're
fumble-fingered and flummoxed by cryptic error messages, then take a
snapshot of the entire repository before any major operation on it, so
that deletion and replacement entirely undoes any embarrassing stuff-up.

Erik

[toc] | [prev] | [next] | [standalone]

#201832

On 10/28/18 10:40 PM, Erik Christiansen wrote:
> On 26.10.18 13:05, David Christensen wrote:
>> When programming, I tend to do check-in's when I make some kind of progress
>> (ideally, the code builds and the test suite passes).
> 
> Yup, the smaller edits of bugfixes aren't going to threaten code stability.

+1  Working solo on personal stuff, I have learned to be less worried 
about checking in broken make and test on the head.  The key is 
finishing and doing the final commit, tag, build, test, install, and 
release before I get distracted by the next thing.


>> The trap is when I work for a while, make some progress, make a wrong turn,
>> and then make a mess.  A versioning file system makes it easy to get back to
>> "make some progress" and try a different turn.
> 
> Yes. If the major hack can be limited to one file, I've been known to
> rely on Vim's undo capability to buffer all the changes long enough for a
> build and test. 

+1


> That could perhaps be extended to several editor
> instances for a couple of files, for a quick but disruptive tentative
> test of a divergent approach.
> 
> The more robust way is though to develop on a VCS branch, check in prior
> to jumping off the cliff, and merge back to trunk when it's all sorted
> and tested.

+1  Definitely branches for anything non-trivial.


>> The compromise is to do a "work in progress" check-in prior to risky turns.
> 
> Yup, but risk can grow after initial edits reveal that additional
> structural changes are needed in order to enable the revised strategy to
> be completely implemented. 

That's when it is time to create a branch and move the working files over.


> In response to that late awareness, I've been
> known to ifdef out the old, to leave it in the file for recovery if a
> massive stone ball comes rolling down the path I've hacked through the
> jungle.

I do Perl:

=pod
=cut

Cut and paste below __END__


> And yes, if CVS is the VCS you're most familiar with, then it's still
> fit for use. Traffic on the ML is rare now, but there is still some
> legacy use out there, and I use nothing else for my own versioning,
> having used it for multi-team international software development for
> many years. Its automatic merging capability alone is a dream.
> 
> OK, git is quicker and preferred for big projects, but for small teams
> of greybeards who were weaned on it, CVS is still fine. 

Okay.


> (And if you're
> fumble-fingered and flummoxed by cryptic error messages, then take a
> snapshot of the entire repository before any major operation on it, so
> that deletion and replacement entirely undoes any embarrassing stuff-up.

+1


Alternatively, copy aside and/or backup the working directory.


David

[toc] | [prev] | [next] | [standalone]

#201712

On Thu, Oct 25, 2018 at 10:33:57PM -0400, songbird wrote:
>  what i really need to do is trust and use git
>commits more but i have a block about some
>things...  *sigh*

That's certainly the best way forward in your case.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#201679

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.

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

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).

-dsr-

[toc] | [prev] | [next] | [standalone]

#201720

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

[toc] | [prev] | [next] | [standalone]

#201726

On Sat, 27 Oct 2018 at 08:23, David Christensen
<dpchrist@holgerdanske.com> wrote:

Hi, I've noticed that you give a lot of good advice on this list. Now, I hope
to return the favour :) ...

> 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.

git is a "standard tool" these days.

> 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

git-cat-file(1)
git-grep(1)
git-diff(1)

> 'CVS' just now, I found zero hits.  This means I'd need to check them

CVS WTF? :)

> 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.

git-rebase(1)

Seriously, learn git. git's own documentation does not make that easy, but
if you search more widely for information and persist, it will be extremely
rewarding in the long run.

[toc] | [prev] | [next] | [standalone]

#201729

On 10/26/18 3:26 PM, David wrote:
> On Sat, 27 Oct 2018 at 08:23, David Christensen
> <dpchrist@holgerdanske.com> wrote:
> 
> Hi, I've noticed that you give a lot of good advice on this list. Now, I hope
> to return the favour :) ...

Thank you; I try.


>> 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.
> 
> git is a "standard tool" these days.

Perhaps.


>> 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
> 
> git-cat-file(1)
> git-grep(1)
> git-diff(1)

     cvs update -p ...

     cvs diff ...


The first operation for both Git and CVS is necessary functionality 
(print a specific revision of a file on standard output).  The second 
and subsequent operations can be performed the Unix Way:

     https://en.wikipedia.org/wiki/Unix_way

     cvs update -p ... | grep ...

     cvs update -p ... | diff - ...

     cvs update -p ... > ... && cvs update -p ... > ... && diff ...


A versioning file system exposes every version of file as a regular 
file, so that every file system aware tool can access it.


A good shell lets you easily combine the files and the tools as desired.


>> 'CVS' just now, I found zero hits.  This means I'd need to check them
> 
> CVS WTF? :)

Yup.


>> 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.
> 
> git-rebase(1)
> 
> Seriously, learn git. git's own documentation does not make that easy, but
> if you search more widely for information and persist, it will be extremely
> rewarding in the long run.

I read the O'Reilly book "Version Control with Git" many years ago, but 
I haven't had a compelling use-case for Git.  (And, I prefer CVS's 
traditional per-file version numbering feature.)


David

[toc] | [prev] | [next] | [standalone]

#201711

On Thu, Oct 25, 2018 at 05:32:52PM -0700, David Christensen wrote:
>Has anybody tried copyfs, fsvs, or anything else with file versioning?

I haven't, but I would postulate that if they worked as well as you
might hope, we'd all already be using them.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#201722

On 10/26/18 12:59 PM, Jonathan Dowland wrote:
> On Thu, Oct 25, 2018 at 05:32:52PM -0700, David Christensen wrote:
>> Has anybody tried copyfs, fsvs, or anything else with file versioning?
> 
> I haven't, but I would postulate that if they worked as well as you
> might hope, we'd all already be using them.

I would postulate that most of us use what is provided OOTB -- e.g. by 
the Debian installer (d-i) -- and what is fully integrated/ supported 
into the distribution -- e.g. Apt, systemd, userspace, whatever.


I wrestled with ZFS on Debian a few years back (on Wheezy?).  Then and 
now, Apt offered the zfs-fuse package.  zfs-fuse was slow and had a 
dated feature set, but it worked and was reasonably well integrated into 
Debian.  ZFS on Linux (ZOL) was available as a download.  I built and 
installed it.  ZOL was performant and up-to-date, but integrating ZOL 
into Debian was my responsibility.  So, I wrote some scripts and hacked 
them into the init and shutdown systems.  ZFS rocked, but my amateur 
integration was brittle.  And, I soon realized that ZFS is unsupported 
by the d-i rescue shell.  Now I use btrfs.


David

[toc] | [prev] | [next] | [standalone]

#201797

On Fri, Oct 26, 2018 at 02:46:16PM -0700, David Christensen wrote:
>I would postulate that most of us use what is provided OOTB -- e.g. by 
>the Debian installer (d-i) -- and what is fully integrated/ supported 
>into the distribution -- e.g. Apt, systemd, userspace, whatever.

Perhaps when I said "we'd already be using them" I shouldn't have
bracketed such a broad group as "us". Let me be clearer: in my 10 years
as a Debian developer, 20 as a user, 10 as a professional sysadmin and 5
as a professional software engineer, I have never met anyone who uses
something like this regularly.

>I wrestled with ZFS on Debian a few years back (on Wheezy?).  Then and 
>now, Apt offered the zfs-fuse package.  zfs-fuse was slow and had a 
>dated feature set, but it worked and was reasonably well integrated 
>into Debian.  ZFS on Linux (ZOL) was available as a download.  I built 
>and installed it.  ZOL was performant and up-to-date, but integrating 
>ZOL into Debian was my responsibility.  So, I wrote some scripts and 
>hacked them into the init and shutdown systems.  ZFS rocked, but my 
>amateur integration was brittle.  And, I soon realized that ZFS is 
>unsupported by the d-i rescue shell.  Now I use btrfs.

I haven't extracted the relevance of this passage to the topic we are
discussing, but I do hope you have a backup system.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#201827

On 10/28/18 11:35 AM, David Christensen wrote:
> Moving bike shed discussion off-list...
> 
> 
> On 10/28/18 7:42 AM, Jonathan Dowland wrote:
>> On Fri, Oct 26, 2018 at 02:46:16PM -0700, David Christensen wrote:
>>> I would postulate that most of us use what is provided OOTB --
>>> e.g. by the Debian installer (d-i) -- and what is fully
>>> integrated/ supported into the distribution -- e.g. Apt, systemd,
>>> userspace, whatever.
>> 
>> Perhaps when I said "we'd already be using them" I shouldn't have 
>> bracketed such a broad group as "us". Let me be clearer: in my 10
>> years as a Debian developer, 20 as a user, 10 as a professional
>> sysadmin and 5 as a professional software engineer, I have never
>> met anyone who uses something like this regularly.
> 
> It sounds like you never used VAX/VMS.
> 
> 
>>> I wrestled with ZFS on Debian a few years back (on Wheezy?).
>>> Then and now, Apt offered the zfs-fuse package.  zfs-fuse was
>>> slow and had a dated feature set, but it worked and was
>>> reasonably well integrated into Debian.  ZFS on Linux (ZOL) was
>>> available as a download.  I built and installed it.  ZOL was
>>> performant and up-to-date, but integrating ZOL into Debian was my
>>> responsibility.  So, I wrote some scripts and hacked them into
>>> the init and shutdown systems.  ZFS rocked, but my amateur
>>> integration was brittle.  And, I soon realized that ZFS is
>>> unsupported by the d-i rescue shell.  Now I use btrfs.
>> 
>> I haven't extracted the relevance of this passage to the topic we
>> are discussing,
> 
> It is a demonstration of my postulate, above.
> 
> 
>> but I do hope you have a backup system.
> 
> Of course.  I also have archive and imaging systems.

On 10/28/18 12:27 PM, Jonathan Dowland wrote:>
> Please don’t. See my on-list sig.

Okay.


David

[toc] | [prev] | [next] | [standalone]

#201862

On Sun, Oct 28, 2018 at 07:54:17PM -0700, David Christensen wrote:
>>It sounds like you never used VAX/VMS.

No, it was decidedly before my time¹. But you seem to be mixed up on the
point I'm making. I fully appreciate the potential utility of a
versioning filesystem: heck, I'd love it if there was a modern, robust
one that I could enable on my Debian system and reap the advantages of
without any drawbacks; I just don't think the packages that you
mentioned (copyfs, davfs2, fsvs, etc.) deliver that experience.


¹ having said that, I'm very interested in things that are from before
  my time. I'm chair of the historic computing committee at Newcastle
  University, UK, and we look after several artefacts from the long 
  history of computing at this University. Some of our most prized bits
  are from the IBM/360 era from the late 1960s to the 1970s. We recently
  took part in a large festival of culture in the city of called the
  "Great Exhibition of the North". More on all that, here:
  <https://blogs.ncl.ac.uk/cs-history/>

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [next] | [standalone]

#201867

On Tue, Oct 30, 2018 at 09:47:33AM +0000, Jonathan Dowland wrote:
>On Sun, Oct 28, 2018 at 07:54:17PM -0700, David Christensen wrote:
>>>It sounds like you never used VAX/VMS.
>
>No, it was decidedly before my time¹.

I have. It was a PITA in practice, which is why other OSs didn't pick up 
the idea and run with it.

[toc] | [prev] | [next] | [standalone]

#201901

On 10/30/18 3:41 AM, Michael Stone wrote:
> On Tue, Oct 30, 2018 at 09:47:33AM +0000, Jonathan Dowland wrote:
>> On Sun, Oct 28, 2018 at 07:54:17PM -0700, David Christensen wrote:
>>>> It sounds like you never used VAX/VMS.
>>
>> No, it was decidedly before my time¹.
> 
> I have. It was a PITA in practice,

I don't recall having problems with the VAX/VMS file system versioning 
feature.  But, perhaps my use-case was simple enough that that I never 
ran into trouble.  What problems did you have with it?


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web