From: Jon Seymour <jon.seymour@gmail.com>
To: Marc Girod <girod@shire.ntc.nokia.com>, git@vger.kernel.org
Subject: A VFS layer - was: SCM ideas from 2003
Date: Tue, 19 Apr 2005 18:07:39 +1000 [thread overview]
Message-ID: <2cfc403205041901074ca57724@mail.gmail.com> (raw)
In-Reply-To: <u0tkboecbuybl.fsf@merleau.ntc.nokia.com>
On 19 Apr 2005 08:31:42 +0300, Marc Girod <girod@shire.ntc.nokia.com> wrote:
> >>>>> "KS" == Kevin Smith <yarcs@qualitycode.com> writes:
>
> KS> "what's so special about files ?" where the author suggests that
> KS> existing SCM systems are so blinded by the tradition of file
> KS> orientation that they can't see that there might be alternatives.
>
> Correct: file orientation is eventually a limitation.
>
> But there are other dimensions to investigate in order to overcome it.
> The issue is to offer a *location* for the possible versions -- not
> only sequential changes but also alternatives.
>
> A directory may be considered as a namespace.
> Note that there are other cases of 'containers': archives, packages,
> libraries, etc...
>
Of course, it is not just SCM's that are "blinded" by file orientation
- every other tool (editors, compilters, etc) that we use has this
orientation. An SCM really has to have some notion of file
orientation, at least at the UI level, because every other tool we use
has the same orientation. The ENVY/VisualAge environments tried to
work with a pure class-level orientation and in some ways that was
great, but most developers hated it precisely because it removed the
file orientation and hence their ability to work with their favourite
tools. IBM/OTI saw the light which is why Eclipse is avowedly a
file-oriented platform.
It seems to me that file-orientation is here to stay and it would be
really cool to layer some kind of virtual filesystem over the git
repository so that different trees become transparently accessible via
different branches of a file system, e.g.:
/mnt/gitfs/working # some kind of writeable
virtual directory over the git cache
/mnt/gitfs/c157067185209b50b350571fe762c2740ea13fc1 # read-only
tree of commit c157...
/mnt/gitfs/5b53d3a08d64198d26d4f2323f235790c04aeaab # read-only
tree of comit 5b53...
Given the purity of Linus' concept and his natural orientation towards
file systems rather than SCMs, this seems like a rather natural thing
to do. If anyone is planning to do this and wants a helper, count me
in!
jon.
--
homepage: http://www.zeta.org.au/~jon/
blog: http://orwelliantremors.blogspot.com/
next prev parent reply other threads:[~2005-04-19 8:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-19 3:38 SCM ideas from 2003 Kevin Smith
2005-04-19 5:31 ` Marc Girod
2005-04-19 8:07 ` Jon Seymour [this message]
2005-04-19 23:13 ` A VFS layer - was: " Stéphane Fillod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cfc403205041901074ca57724@mail.gmail.com \
--to=jon.seymour@gmail.com \
--cc=girod@shire.ntc.nokia.com \
--cc=git@vger.kernel.org \
--cc=jon@zeta.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).