On Tue, Jan 16, 2001 at 11:59:56PM +0100, Branko ?ibej wrote:
> Kevin Pilch-Bisson wrote:
>
> > Okay on to file systems.
> >
> > I was thinking that it would be nice to have a file system which does
> > the following.
>
> I worked on such a file system (actually a file server) for 4+ years, so
> I have some idea about the problems involved.
Great!
>
> > 1) Stores all the revisions (including history) of a file. The same as
> > subversion does, but implemented at the file-system layer, so that any
> > time a change is made, it is in a way automatically committed.
>
> Oops. How do you know when a change was made? After each write, after
> each close, or after all handles to a file have been closed? What about
> ch{mod,acl,usr,grp}?
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.)
>
> Another thing you have to think about is what to do with temporary
> files. Backup files from editors, object and other temporary files from
> compilers, etc. If you automatically place those under version control,
> you'll end up with all sorts of crud in the repository.
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.
>
> 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. Maybe allow two
modes of operation, i.e. autocommit and manual commit.
>
> > 2) Beyond that it should allow all the normal cvs type operations,
> > tagging, diffs, retrieval of past labels/versions, etc.
>
> Oops again. That's not the filesystem's job. All of those belong to the
> extended API.
Of course! I should have said it would provide that functionality to a
set of userland programs, somewhat like e2fstools.
>
> > _AND_ it should
> > allow retrieval of a file (or tree) based on a timestamp (so you could
> > say something like: make my system the way it was yesterday before I
> > made all these crazy changes to it).
>
> This is a normal CM operation. You also want to move a whole filesystem
> (or subtree) to another branch, etc.
>
> On the other hand, you may want to think about exposing the version tree
> in the filesystem, say from a special kind of mount point. The
> possibilities are endless.
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. Obviously one of those helper progs would list the
revs, presumably with the date of creation, etc.
>
>
> > 3) In addition it would be nice to have tools to move old parts of the
> > tree onto permanent storage so that disk-space is not wasted
> > indefinitely. I.e. move the repository to tape/CDROM/etc, then replace
> > it with a sort of new repository with the current files as the
> > originals.
>
> Now /that/ is something I'd like to see in Subversion. Right now the SVN
> filesystem design doesn't allow something like that, since committed
> nodes are immutable, but I'm sure we could change the design slightly to
> support archiving of old versions.
Good to see you like at least _ONE_ of my ideas :)
>
> The simplest way (and possibly a first step) would be to simply allow a
> file's text to be stored offline (i.e., besides having "fulltext" and
> "younger" file nodes, we'd also have "offline" nodes). This would keep
> all history and tree info intact, just make the contents unavailable.
I haven't looked at the source for subversion enough yet, but I'll take
your word for it.
>
> Hmm. Must remember to put this in IDEAS.
>
>
> > What does everyone think of a file system like this. Personally I think
> > it would be extremely useful! Is anyone interested in helping me learn
> > enought about file systems and version control to actually implement
> > something like this?
>
> It's definitely a useful concept. I've been thinking about having
> something like ClearCase's dynamic views for Subversion -- these are a
> bit like a versioned filesystem, but only accessible over the network.
> They're useful because a client doesn't have to create a local working
> copy. This can be a significant savings (in disk space /and/ network
> traffic) if your source tree is 1 GB and you have to work on three
> branches at once, which I happen to be doing right now at work. :-)
>
I haven't used ClearCase, but I can see what you mean.
>
> 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 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.
Anyway, thanks for all the great feedback!
>
> --
> 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/
--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson
kevin@pilch-bisson.net
http://www.pilch-bisson.net
- application/pgp-signature attachment: stored
Received on Sat Oct 21 14:36:19 2006