From: Larry McVoy <lm@bitmover.com>
To: Kent Borg <kentborg@borg.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Versioning File Systems?
Date: Thu, 18 Apr 2002 08:20:25 -0700 [thread overview]
Message-ID: <20020418082025.N2710@work.bitmover.com> (raw)
In-Reply-To: <20020418110558.A16135@borg.org>
On Thu, Apr 18, 2002 at 11:05:58AM -0400, Kent Borg wrote:
> Seriously, I have a server in the basement with a pair of 60 GB RAID 1
> disks the protect me against likely hardware failure, but they don't
> protect me against: "# rm rf /*". They don't even let me easily back
> out a bad RPM from Red Hat.
To protect agains rm -rf /, you need backups, not raid. We do that here
with scripts which just mirror the whole file system to a different drive
every night. Saves us a ton of grief and gives us a very simplistic
version control system, I do stuff like
diff foo.c /nightly/$PWD
all the time for data which isn't in a version control system.
> I guess I am suggesting the (more constructive) discussions over
> desirable Bitkeeper and CVS features consider what it would mean for a
> filesystem to absorb some of the key underlying features of each.
It's certainly a fun space, file system hacking is always fun. There
doesn't seem to be a good match between file system operations and
SCM operations, especially stuff like checkin. write != checkin.
But you can handle that with
echo "I'm done" >> foo.c/checkin
i.e., when the file is treated as a directory, use the rest of the
pathname as the operation. Could be cool.
One other thing you might consider, is gluing an SCM system into
the user level NFS server. That has the nice attribute that you
can export your file system/SCM system. And/Or samba.
The real issue with all of this is that you can make it work
locally by extending your pathname sematics or some other
thing, but I've never figured out how to make it work remotely
without hacking the remote OS. Cross platform is important,
at least it is commercially.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2002-04-18 15:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 15:05 Versioning File Systems? Kent Borg
2002-04-18 15:20 ` Larry McVoy [this message]
2002-04-18 15:27 ` Lars Marowsky-Bree
2002-04-18 16:55 ` Kent Borg
2002-04-18 17:04 ` Joshua MacDonald
2002-04-20 8:44 ` Thomas Zimmerman
2002-04-18 23:19 ` Stevie O
2002-04-19 4:12 ` Mark Mielke
2002-04-18 18:11 ` Jeremy Jackson
2002-04-23 22:42 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2002-04-18 16:51 Kerl, John
2002-04-18 17:24 ` Florin Iucha
2002-04-18 18:14 ` Kent Borg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020418082025.N2710@work.bitmover.com \
--to=lm@bitmover.com \
--cc=kentborg@borg.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox