public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Larry McVoy <lm@bitmover.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Jerome de Vivie <jerome.de-vivie@wanadoo.fr>,
	Larry McVoy <lm@bitmover.com>,
	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 16:14:54 -0700	[thread overview]
Message-ID: <20010723161454.C14425@work.bitmover.com> (raw)
In-Reply-To: <3B5CA2EC.2498775@wanadoo.fr> <Pine.LNX.4.33L.0107231925040.20326-100000@duckman.distro.conectiva>
In-Reply-To: <Pine.LNX.4.33L.0107231925040.20326-100000@duckman.distro.conectiva>; from riel@conectiva.com.br on Mon, Jul 23, 2001 at 07:29:36PM -0300

On Mon, Jul 23, 2001 at 07:29:36PM -0300, Rik van Riel wrote:
> Now if you want to make this kernel-accessible, why
> not make a userland NFS daemon which uses something
> like bitkeeper or PRCS as its backend ?
> 
> The system would then look like this:
> 
>  _____    _______    _____    _____
> |     |  |       |  |     |  |     |
> | SCM |--| UNFSD |--| NET |--| NFS |
> |_____|  |_______|  |_____|  |_____|
> 
> 
> And there, you have a transparent SCM filesystem
> that works over the network ... without ever having
> to modify the kernel or implement SCM.

I like the way you think, Rik.  About 2 years ago I did a very quick and ugly
version of exactly this, just as a proof of concept.  You could mount old
versions of the repositories and diff them, etc.  Quite cool.  It's long
since out of date and it adds a layer of caching and performance loss that
I wasn't willing to live with, but it's a cool idea.  When we have more time
than problems I might get back to that.  I think it is the right approach.

As to the comments he made about mixing files, that's not a problem.  You
do need some way to tell UNFDS that this file is to be revision controlled
and that one is not, but with that you can let .o's be created and just 
managed in the backing file system.  Works fine.  The interface to 
revision control stuff seems ugly because you have to be explicit, but that
can be made nice.  Suppose we used fake subdirectories as a way of doing
operations, such that

	mv *.c ./.checkin

does a checkin, etc.  That's not so bad and you need the interface anyway 
to tell the system you are ready to check things in. You don't want it to 
check in a new version every time you modify the file, that's excessive.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

  parent reply	other threads:[~2001-07-23 23:15 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 [this message]
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
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=20010723161454.C14425@work.bitmover.com \
    --to=lm@bitmover.com \
    --cc=jerome.de-vivie@wanadoo.fr \
    --cc=linux-fsdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martizab@libertsurf.fr \
    --cc=riel@conectiva.com.br \
    --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