public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc: Larry McVoy <lm@bitmover.com>,
	Jerome de Vivie <jerome.de-vivie@wanadoo.fr>,
	linux-kernel@vger.kernel.org, linux-fsdev@vger.kernel.org,
	martizab@libertsurf.fr, rusty@rustcorp.com.au
Subject: Re: Yet another linux filesytem: with version control
Date: Mon, 23 Jul 2001 22:34:13 -0700	[thread overview]
Message-ID: <20010723223413.G15284@work.bitmover.com> (raw)
In-Reply-To: <20010723141751.W6820@work.bitmover.com> <200107240524.f6O5OwX286884@saturn.cs.uml.edu>
In-Reply-To: <200107240524.f6O5OwX286884@saturn.cs.uml.edu>; from acahalan@cs.uml.edu on Tue, Jul 24, 2001 at 01:24:57AM -0400

> > b) Filesystem support for SCM is really a flawed approach.  No matter how
> >    much you hate all SCM systems out there, shoving the problem into the
> >    kernel isn't the answer.  All that means is that you have an ongoing
> >    battle to keep your VFS up to date with the kernel.  Ask Rational
> >    how much fun that is...
> 
> I'm sure it is a pain to maintain, but consider recovery
> with revision control in your root filesystem:
> 
> LILO: linux init=/bin/sh rootfsopts=ver:/bin/sh@@/main/1
> 
> Nice, isn't it? You can trash /bin/* all you want.

Yeah, that's cool.  I'm with you in spirit on this one Albert, I've long
promoted that we use revision control for all the config files (stuff
like /etc/sendmail.cf, etc).

And we have customers who use BitKeeper to manage their entire OS, I mean
all the binaries are in there. 

That said, I'd really urge people to listen to Rik, he has the right idea
with the user level NFS idea.  There is no good reason and a lot of bad
reasons to put this stuff in the kernel.

I realize that since this is our business that my credibility is low,
you'll expect that I'm pushing this because it somehow benefits us (how,
I'm not sure, but I have faith that someone will think that).  Anyway,
that's not the case, this is purely from a kernel point of view, I think
this is a dead end.

Useful stuff would be the copy on write file system, that's good for SCM
and other things.  And the user level NFS approach.  That way if you hate
the BK license you can plug PRCS or CVS or my-favorite-SCM system into the
back end.  I'd much rather see that than BK in the kernel.  Yuck.

> Distributed filesystems like Coda seem to get pretty close
> to having revision control anyway. They need something like
> it for conflict resolution.

Yeah!  No kidding.  If Coda had this I think there is a reasonable chance
that most SCM systems would go away.  Certainly the trivial ones would.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

  reply	other threads:[~2001-07-24  5:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-23 21:06 Yet another linux filesytem: with version control Jerome de Vivie
2001-07-23 21:17 ` Larry McVoy
2001-07-23 21:51   ` Rik van Riel
2001-07-23 22:19     ` Jerome de Vivie
2001-07-23 22:29       ` Rik van Riel
2001-07-23 23:05         ` Jerome de Vivie
2001-07-23 23:30           ` Rik van Riel
2001-07-24 13:30             ` Olivier Galibert
2001-07-24 16:42             ` Jerome de Vivie
2001-07-23 23:14         ` Larry McVoy
2001-07-24 23:57       ` Peter A. Castro
2001-07-23 22:00   ` Jerome de Vivie
2001-07-23 22:14     ` Larry McVoy
2001-07-23 22:27       ` Jerome de Vivie
2001-07-24  5:24   ` Albert D. Cahalan
2001-07-24  5:34     ` Larry McVoy [this message]
2001-07-24  6:06       ` Alexander Viro
2001-07-24  9:30       ` Padraig Brady
2001-07-24 19:07     ` Jan Harkes
2001-07-24  2:13 ` Keith Owens
2001-07-24 13:07 ` Andrew Pimlott
2001-07-24 17:14   ` Jerome de Vivie
2001-07-24 19:05     ` Andrew Pimlott
2001-07-24 23:14       ` Jerome de Vivie
2001-07-25  0:39         ` Andrew Pimlott
  -- strict thread matches above, loose matches on Subject: below --
2001-07-23 22:50 Florin Iucha

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=20010723223413.G15284@work.bitmover.com \
    --to=lm@bitmover.com \
    --cc=acahalan@cs.uml.edu \
    --cc=jerome.de-vivie@wanadoo.fr \
    --cc=linux-fsdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martizab@libertsurf.fr \
    --cc=rusty@rustcorp.com.au \
    /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