Re: Versioned FS (Was Re: An Intro)

Kevin Pilch-Bisson wrote:

> I was thinking along the lines of after each close. Anyone know how VMS
> did it. (Disclaimer, I have never used VMS, just heard about it from some
> who have.)

VMS doesn't really have a versioned filesystem: it has versions of
files, not the same thing. And you always see all versions, and can
delete old ones. At every open for write, a new version of the files is
created unless you specify the full name, including the version number,
in the call.

Here's a live session transcript:

$ dir

Directory E4$:[BRANE.WORK]

EXAMPLE.TXT;1 14/16 Tue, 9-Jan-1996 10:08:47 (RWE,RWED,R,R)

Total of 1 files, 14/16 blocks.
$ ed example.txt
$ dir

Directory E4$:[BRANE.WORK]

EXAMPLE.TXT;2 14/16 Wed, 17-Jan-2001 21:01:50 (RWE,RWED,R,R)
EXAMPLE.TXT;1 14/16 Tue, 9-Jan-1996 10:08:47 (RWE,RWED,R,R)

Total of 2 files, 28/32 blocks.
$ purge
%PURGE-I-FILPURG, E4$:[BRANE.WORK]EXAMPLE.TXT;1 deleted (16 blocks)
$ dir
Directory E4$:[BRANE.WORK]

EXAMPLE.TXT;2 14/16 Wed, 17-Jan-2001 21:01:50 (RWE,RWED,R,R)

Total of 1 files, 14/16 blocks.
$

You get the idea. If I had edited "example.txt;1", version 2 wouldn't
have been created

That's simple enough if only one process at once opens a file. But
things don't necessarily happen that way, and dealing with simultaneous
opens in a sane way can be /very/ frustrating.

> I have been thinking about this, and the only thing I can think of is to
> have some way to specify what files should not be in the repository,
> e.g. *~,*.o etc. Obviously this would have to be configurable in some
> way.

Hmm, something like .cvsignore. Yes, that would work in general.

>> In general it's a bad idea to try to guess when a change is complete.
>> Whatever approach you take, it'll be wrong for some tool/use model. The
>> only safe way I know is to have the user state explicitly when a change
>> is complete; e.g., use an extended API, say filesystem-specific IOCTLs,
>> then write a command-line tool on top of those.
>
>
> That is another approach, but I see it as also having problems, mainly
> that a lot of users wouldn't tend to use it properly.

True, but "a lot of users" wouldn't need it, either. Using a version
control system takes some discipline.

> Maybe allow two
> modes of operation, i.e. autocommit and manual commit.

Maybe.

> I agree. From what I have heard about VMS, if you just typed 'vi foo.c'
> you would get the latest rev, but you could also type 'vi foo.c:27' to
> get rev 27 of foo.c.

Yes, but as I said, a file version in VMS is just an ordinary file, with
a bit of magic going on for name generation. That's definitely not what
you want, right?

> Good to see you like at least _ONE_ of my ideas :)

Oh, I wasn't stomping on your ideas for fun. Just trying to take away
the pleasure of learning from your own mistakes. :-)

>> Kevin, if you want to work on this, let me suggest you stay away from
>> kernel code and Linux specifics for now. I think a good approach would
>> be to write a Samba VFS module on top of Subversion; the benefits are
>> that you stay in userland (a good thing for initial development) and
>> you're not bound to a single platform. It's been some time since I last
>> took a hack at Samba, but I'm sure you'll be able to find your way
>> around. If not, holler.
>>
>
> Oky, I'll take a look at some of the Samba stuff.

I took a few minutes yesterday to ge up to date. Seems that Samba 2.2,
which will be released RSN, will finally have support for VFS modules
built in. Except that it doesn't do IOCTLs yet, so that'll have to be
added if you want to use them. Maybe I'll go ahead and take another hack
at Samba after all this time, yay! :-)

But: Take a good look at the Subversion sources first, you'll need them
far more than the Samba bits.

> I really have no
> experience doing this kind of thing, and I haven't started, so it makes
> sense to explore my options before starting. Most of my development in the past
> has been End-User level C++ stuff, with the exception of my OS and
> Compiler courses at school.

Well, it's a good time to start, then. :-)

> Anyway, thanks for all the great feedback!

You're welcome.

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/