Re: Yet another linux filesytem: with version control

Jerome de Vivie (jerome.de-vivie@wanadoo.fr)
Tue, 24 Jul 2001 19:14:02 +0200


Andrew Pimlott a écrit :
>
> 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.)

Yes: co is now a "copy on write", so it's automatic.

>
> > When a C-file is created,
>
> Presumably this is an explicit operation? What system call?

Yes it's explicit. I know though about a userspace solution but
i would have added a "O_CREATE like" flags on open, or use ioctl.

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

No.

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

Yes.

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

Yes. Probably with a ioctl (but now with a user command !)

>
> > 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
> independently?

It's impossible. If you want to go back, you have to put a label on
each step you want and, set the $CONFIGURATION to this label.

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

With 2 process and shared memory, it should be possible but i haven't
though deeper.

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

A developper has a minimum operation to do:
-set his configuration
-commit his work

That's all ! No branch, no config-spec, no view server, no vob server,
no registery server, no ci, no co, ...

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

1. You stop from this new "branch".
2. You commit your work with a new label.
3. You set $CONFIGURATION to the good label and merge the previous
work into.

>
> How will the existing merge tool work, if a single process can only
> see one $CONFIGURATION?

Same as for diff (...but now, obolete)

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

Copy-on-write was the first new idea. Using the same system
(labelization) to identify both individual version and configuration
is also a neat idea. The last one is "hacking the nfsd" (thx Rik !)
I'm sure that we can handle SCM differently.

regards,

j.

-- 
Jerome de Vivie 	jerome . de - vivie @ wanadoo . fr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/