{"thread":{"id":"125","subject":"SCM ideas from 2003","startedAt":"2005-04-19T03:38:37Z","lastAt":"2005-04-19T23:13:36Z","messageCount":4,"participants":["Kevin Smith","Marc Girod","Jon Seymour","Stéphane Fillod"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"779","messageId":"42647D3D.6030906@qualitycode.com","threadId":"125","inReplyTo":null,"subject":"SCM ideas from 2003","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-04-19T03:38:37Z","receivedAt":"2005-04-19T03:38:37Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"I just stumbled across this page, dated 2003, which foreshadows a couple\nof the decisions Linus has made for git:\n\n http://ydirson.free.fr/en/software/scm/vc.txt\n\nHere are the parts that particularly caught my eye:\n\n\"what's so special about files ?\" where the author suggests that\nexisting SCM systems are so blinded by the tradition of file orientation\nthat they can't see that there might be alternatives.\n\n\"As a goodie we can even note that moving a file inside the hierarchy\nhas become exactly similar as moving a code statement.\" where the author\nrecognizes that renames are merely a special case of code moves.\n\nHis implementation ideas are quite different from git, but I thought it\nwas pretty cool to find that someone was thinking about these ideas a\ncouple years ago.\n\nKevin\n"},{"id":"788","messageId":"u0tkboecbuybl.fsf@merleau.ntc.nokia.com","threadId":"125","inReplyTo":"42647D3D.6030906@qualitycode.com","subject":"Re: SCM ideas from 2003","fromName":"Marc Girod","fromEmail":"girod@shire.ntc.nokia.com","sentAt":"2005-04-19T05:31:42Z","receivedAt":"2005-04-19T05:31:42Z","isPatch":false,"sender":{"key":"girod@shire.ntc.nokia.com","avatar":null},"body":">>>>> \"KS\" == Kevin Smith writes:\n\nKS> \"what's so special about files ?\" where the author suggests that\nKS> existing SCM systems are so blinded by the tradition of file\nKS> orientation that they can't see that there might be alternatives.\n\nCorrect: file orientation is eventually a limitation.\n\nBut there are other dimensions to investigate in order to overcome it.\nThe issue is to offer a *location* for the possible versions -- not\nonly sequential changes but also alternatives.\n\nA directory may be considered as a namespace.\nNote that there are other cases of 'containers': archives, packages,\nlibraries, etc...\n\n-- \nMarc Girod P.O. Box 323 Voice: +358-71 80 25581\nNokia BI 00045 NOKIA Group Mobile: +358-50 38 78415\nValimo 21 / B616 Finland Fax: +358-71 80 64474\n\n"},{"id":"789","messageId":"2cfc403205041901074ca57724@mail.gmail.com","threadId":"125","inReplyTo":"u0tkboecbuybl.fsf@merleau.ntc.nokia.com","subject":"A VFS layer - was: SCM ideas from 2003","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-04-19T08:07:39Z","receivedAt":"2005-04-19T08:07:39Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 19 Apr 2005 08:31:42 +0300, Marc Girod wrote:\n> >>>>> \"KS\" == Kevin Smith writes:\n> \n> KS> \"what's so special about files ?\" where the author suggests that\n> KS> existing SCM systems are so blinded by the tradition of file\n> KS> orientation that they can't see that there might be alternatives.\n> \n> Correct: file orientation is eventually a limitation.\n> \n> But there are other dimensions to investigate in order to overcome it.\n> The issue is to offer a *location* for the possible versions -- not\n> only sequential changes but also alternatives.\n> \n> A directory may be considered as a namespace.\n> Note that there are other cases of 'containers': archives, packages,\n> libraries, etc...\n> \n\nOf course, it is not just SCM's that are \"blinded\" by file orientation\n- every other tool (editors, compilters, etc) that we use has this\norientation. An SCM really has to have some notion of file\norientation, at least at the UI level, because every other tool we use\nhas the same orientation. The ENVY/VisualAge environments tried to\nwork with a pure class-level orientation and in some ways that was\ngreat, but most developers hated it precisely because it removed the\nfile orientation and hence their ability to work with their favourite\ntools. IBM/OTI saw the light which is why Eclipse is avowedly a\nfile-oriented platform.\n\nIt seems to me that file-orientation is here to stay and it would be\nreally cool to layer some kind of virtual filesystem over the git\nrepository so that different trees become transparently accessible via\ndifferent branches of a file system, e.g.:\n /mnt/gitfs/working # some kind of writeable\nvirtual directory over the git cache\n /mnt/gitfs/c157067185209b50b350571fe762c2740ea13fc1 # read-only\ntree of commit c157...\n /mnt/gitfs/5b53d3a08d64198d26d4f2323f235790c04aeaab # read-only\ntree of comit 5b53...\n\nGiven the purity of Linus' concept and his natural orientation towards\nfile systems rather than SCMs, this seems like a rather natural thing\nto do. If anyone is planning to do this and wants a helper, count me\nin!\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"906","messageId":"loom.20050420T003535-908@post.gmane.org","threadId":"125","inReplyTo":"2cfc403205041901074ca57724@mail.gmail.com","subject":"Re: A VFS layer - was: SCM ideas from 2003","fromName":"Stéphane Fillod","fromEmail":"fillods@gmail.com","sentAt":"2005-04-19T23:13:36Z","receivedAt":"2005-04-19T23:13:36Z","isPatch":false,"sender":{"key":"fillods@gmail.com","avatar":null},"body":"Jon Seymour gmail.com> writes: \n[...] \n> It seems to me that file-orientation is here to stay and it would be \n> really cool to layer some kind of virtual filesystem over the git \n> repository so that different trees become transparently accessible via \n> different branches of a file system, e.g.: \n> /mnt/gitfs/working # some kind of writeable virtual \ndirectory over the git cache \n> /mnt/gitfs/c157067185209b50b350571fe762c2740ea13fc1 # read-only tree of \ncommit c157... \n> /mnt/gitfs/5b53d3a08d64198d26d4f2323f235790c04aeaab # read-only tree of \ncomit 5b53... \n \nAh, you mean wrapping the libgit in a FUSE plugin and let \nthe Linux pagecache/dentry cache do the caching of on-demand \ninflated blobs and indexes? Would the hash be the \"inode number\"? \n \n \n-- \nStephane \n\n"}]}