Read only filesystems

Chris Pressey cpressey@REDACTED
Tue Apr 8 00:31:22 CEST 2003


On Sat, 05 Apr 2003 14:25:05 -0800
Jay Nelson <jay@REDACTED> wrote:

> Chris Pressey wrote:
> 
>  > Researching the topic a tiny bit with Google, it seems to
>  > have a lot to do with the definition of the word "journalling"
>  > in the minds of the people who design the journalling file
>  > system.
> 
> I read a bit about XFS and then a lot about ReiserFS.
> Apparently the goal of the latter is database query capability
> on the filesystem itself.  Interesting approach.  I was thinking
> of using mnesia, but I might consider a filesystem if the
> meta data for versions and dates can be applied.

Depends on exactly what they mean when they say 'database query', but
yes, being able to locate objects based on something besides the
de-facto standard hierarchical path, would be good.  Keywords, for
example.  Current 'find' utilities for OS'es/filesystems are pretty weak
when compared to, say, Google.  And hierarchies are pretty suffocating -
it matters little if I put a file in chris/erlang/doc or
chris/doc/erlang or doc/chris/erlang or doc/erlang/chris.  Those should
really be keywords rather than hierarchical directory names.

>  > It would be neat to see something a bit more explicit
>  > (a bit like CVS or a wiki, perhaps,) where you could select
>  > an object and select "revert to" and pick a date.
> 
> I don't want to view a file as a static current version.

I know you don't want to view a file as static.  But do you really have
a practical choice not to see *some* kind of current version?

> I want all versions always available (until I explicitly destroy them
> or they age off).

I know.

> "reverting" shouldn't be a needed concept.

Unfortunately "transverting" is not good English... at least not yet :)

I don't actually think "revert" is too far off the mark.  As soon as you
switch the view of an object to a different version, the version you
select becomes the newest version (by virtue of the fact that the chosen
version is the one you're going to base your next version on.)  Even
when you, say, switch to a version from a week ago, the version you were
just working on becomes an old version - old, when compared to your
current version (which is a new copy of the version from a week ago.)

Clear as mud :)

> There are multiple read-only files, one of which is currently
> "published"

That's the current version, as I see it.

> if you are sharing with others and want a snapshot view.

I think most people *will* want a "snapshot" view, as the default. 
Actually, I can't really imagine any practical alternatives to having a
single current view of all objects -- wouldn't anything else get
extremely messy?

>  You can change which version a
> published view contains, but you can always open any file
> or "modify" (i.e. create a new copy with different details)
> any version.

To me, it seems a lot easier to split that into two steps:
- switch which version is the current version
- open or "modify" the current version (to make the next new version)

And, from a usage perspective, if the capability to switch versions is
part of (say) the open-file dialog, there's no perceptible difference.

At the risk of confusing this even more, I guess I could try an analogy
here.  You always edit a text file from the cursor position.  You can't
edit the text in any other location; if you want to edit text in some
other location, you have to move the cursor there first.  The "current
version" or "published view" of an object, is analogous to the cursor in
a text editor.

> Semantically the same as what you said probably, but the
> concept of thinking of "revert" puts one in the single modifiable
> file mindset.

I don't see this is a problem, as long as it doesn't exclude other
mindsets.  The "destructive assignment" mindset is, in fact, something
humans are very used to (e.g. you can't unburn a candle) so I see no
reason to abandon it outright.

> I want to think more along the lines of infinite
> undo even after I have turned my computer off and come back
> after a week.

I don't really see how those circumstances make things much different,
but I certainly don't want to stop you from thinking in that mindset
either.

> jay

-Chris



More information about the erlang-questions mailing list