Re: Yet another linux filesytem: with version control

From: Andrew Pimlott (
Date: Tue Jul 24 2001 - 08:07:04 EST

On Mon, Jul 23, 2001 at 11:06:34PM +0200, Jerome de Vivie wrote:
> >From CVS to ClearCase, i haven't seen any easy tool. I feel a real
> need to handle SCM simply.

I think your approach is too simple. ClearCase is a monster, but at
the core is conceptually sound (assuming the goal is file-based
control, not change-set-based; Rational has tried to layer a
change-set-based product on top of ClearCase, and I hear it is a
mess). By comparison you are missing some important things, some of
which I will try to point out.

> Here's the main features:
> -no check-out/check-in

(You do have check-in, you just call it something else.)

> When a C-file is created,

Presumably this is an explicit operation? What system call?

> the label "init" is put onto. The first
> write on a C-file create a private copy for the user who run the
> process. This C-file is added to a "User File List" (UFL). This
> private copy is now selected by the FS in place of version "init".
> Each user can start his own private copy by writting into a C-file.

per-user? So how do I let another developer look at what I'm
working on? In ClearCase, it's one private version per-view, which
is much more flexible.

Does the private copy know which label it was branched from? This
is essential.

> When a developper has reach a step and, would like to share his work;
> he creates a new label.

Ie, check-in by a different name. What system call?

> This label will be put on every private copy
> listed in the UFL and, the UFL is zeroed.

If I have to check in all files at once, it is even more important
that I be able to have multiple "views". What if, in the middle of
a big change, I make a small fix that I want to check in

> First, if the C-file is into the UFL, we have a private copy to
> select. Else, we choose the version labeled by "$CONFIGURATION". If
> such version does not exist, we search the version marked by the
> nearest "parent" label (at least, label "init" match).

You just threw away the most useful feature of filesystem
integration: comparing different versions. How do I do this if
everything is keyed off $CONFIGURATION?

I really don't see what you've gained over CVS. (Once you add in
all the little things you didn't mention: setting up the filesystem,
adding files to version control, etc, I don't think you can argue
that your system is simpler.)

Also, what if you create a label, but forget to update
$CONFIGURATION, and start to make more changes? You can just say
"stupid user", but the fact that this failure mode exists is a wart.

> In userland, we need:
> -a "mklabel" tool.
> -use a "CONFIGURATION" environment variable.
> -use existing tool for "merge" operations.

- setup filesystem
- add file to version control
- list labels, private files (what system calls?)

How will the existing merge tool work, if a single process can only

Here's my conclusion: The overall semantics of a version control
system are non-trivial and should be kept out of the kernel. The
real win with kernel integration is transparent, flexible, read-only
access to versions. Your scheme puts unnecessary stuff in the
kernel, without getting the most important thing right.

(The only other potential win I see with kernel integration is
check-out-on-write, but that doesn't sound like a big deal to me.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:15 EST