threads / discuss / 125

SCM ideas from 2003

Subject: SCM ideas from 2003

## tl;dr

4 messages between Apr 19, 2005 and Apr 19, 2005.

replies: 3people: 4as markdown or json

Kevin Smith· Apr 19, 2005, 03:38 UTC · lore

I just stumbled across this page, dated 2003, which foreshadows a couple of the decisions Linus has made for git:

  http://ydirson.free.fr/en/software/scm/vc.txt

Here are the parts that particularly caught my eye:

"what's so special about files ?" where the author suggests that existing SCM systems are so blinded by the tradition of file orientation that they can't see that there might be alternatives.

"As a goodie we can even note that moving a file inside the hierarchy has become exactly similar as moving a code statement." where the author recognizes that renames are merely a special case of code moves.

His implementation ideas are quite different from git, but I thought it was pretty cool to find that someone was thinking about these ideas a couple years ago.

Kevin

Marc Girod· Apr 19, 2005, 05:31 UTC · re: Kevin Smith · lore

Re: SCM ideas from 2003

>>>>> "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...

-- 
Marc Girod        P.O. Box 323        Voice:  +358-71 80 25581
Nokia BI          00045 NOKIA Group   Mobile: +358-50 38 78415
Valimo 21 / B616  Finland             Fax:    +358-71 80 64474

Jon Seymour· Apr 19, 2005, 08:07 UTC · re: Marc Girod · lore

A VFS layer - was: SCM ideas from 2003

On 19 Apr 2005 08:31:42 +0300, Marc Girod <girod@shire.ntc.nokia.com> wrote:

Show 16 quoted lines

> >>>>> "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/

Stéphane Fillod· Apr 19, 2005, 23:13 UTC · re: Jon Seymour · lore

Re: A VFS layer - was: SCM ideas from 2003

Jon Seymour <jon.seymour <at> gmail.com> writes: [...]

Show 5 quoted lines

> 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... 
 
Ah, you mean wrapping the libgit in a FUSE plugin and let 
the Linux pagecache/dentry cache do the caching of on-demand 
inflated blobs and indexes? Would the hash be the "inode number"? 
 
 
--  
Stephane