On Aug 20, 10:53 am, [EMAIL PROTECTED] (Uriel) wrote:
> Sad thing is that when you try to convince Unix people of the power of
> private namespaces, they complain that they seem 'too confusing'...
> yea, because symlinks, extended attributes and other such hideous
> hacks are so much nicer...
Let's return to my original post and one of the use cases I mentioned
there. Say I have TeX document with innumerable sections in it,
sections that I would like to handle 'file style', for good
interaction with version control. I do not want a lot of include
directives and other crap, though -- I don't want to actually make the
new files. Let us imagine a TeX filesystem:
sec/
matter
images
sec0/
matter
sec1/
...and so on...
This filesystem has two forms -- serialized form and hierarchical
form. In serialized form, it is a TeX file; I mount this file to get
the example above.
Now, here is the tough part, I think -- say I want to use version
control with the above example. I check the directories into my
version control system, which pollutes the TeX fs with a bunch of .svn
directories. This makes my filesystem puke; so I rewrite it to ignore
the .svn thingies. Very good; but, I'm still not finished. Because I
checked the dirs, and not their serialized master, into version
control, I have big problem when I check the thing back out -- it is
now a normal filesystem, full of files and dirs, that has forgotten
it's TeX nature. I have to do a cast -- Iinstantiate it as a normal fs
and then cast it to a TeX fs.
That seems pretty unworkable to me, but I'm very new to Plan 9 and
there's probably something here I'm missing. With attributes and my
dir/file system, there is only one way to mount something, so I am in
no danger of losing my metadata when I try to compose filesystems (in
this case, I am composing an ad-hoc 'version controlled filesystem'
with a TeX filesytem). I can use more than one kind of metadata at a
time. However, in the metadata-in-fs approach, a resource can only be
governed by metadata from one or another filesystem at any given time;
a real problem for the application I am considering.
