On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian <skip.tavakkol...@gmail.com> wrote: > > i like git. as it is a kind of archival file system, one should be able to > build a plan9 file system interface for it.
Have you looked at porting git to plan9? 178K lines of *.[ch]. 20K lines of shell scripts (+ 100K+ lines of test scripts). Also python and perl scripts. All SCM are in some sense archival systems but the actual storage scheme used is just one tiny part of the system. There are a few more requirements which a simple filesystem model won't satisfy by itself. Consider: This is the most fundamental operation of a SCM is to manage source code updates sanely. Suppose you had to change files f1..fn to implement a feature/bugfix. Now you want to check them in and share these changes with others. But the checkin should succeed *only if* the latest versions of f1..fn in the underlying filesystems are the *same* as the ones you started from. If this is not true, the entire checkin must be aborted. It is upto the developer to merge his changes with the latest versions and try again. [Essentially you are doing a compare-and-swap operation on a set of files] You can single thread this through a human but the problem remains the same and a human (without additional tools) will not be able to check all this reliably. For a collaborative, distributed project where different people may work on different parts, a human in the middle is not a scalable solution. The only reason for a manual SCM is to *slow down* the rate of change. Then there other operations like maintaining separate branches, merging/cherry picking changes from another branch, reverting from local changes, rolling back a bad checkin, pushing changes to a shared repo, pulling from it, access control, etc. etc. You can certainly build something on top of venti to build a nice SCM but that would be a researchy project. Given all this I think hg makes a good compromise if you want to move forward from the status-quo.
