> Features such as atomic commits, changesets, branches, push, > pull, merge etc. can be useful in multiple contexts so it > would be nice if they can integrated smoothly in an FS. > > - Installing a package is like a pull (or if you built it > locally, a commit) > - Uinstall is reverting the change. > - Each machine's config can be in its own branch.
what is the advantage over seperate files? imo, this complicates the issue. > - You can use clone to create sandboxes. > - A commit makes your private temp view permanent and > potentially visible to others. > - Conversely old commits can be spilled to a backup > media (current SCMs want the entire history online). > - Without needing a permanent connection you can `pull' data. > [never have to do `9fs sources; ls /n/sources/contrib'.] this is a nice list, but i think a key point is not being teased out. the dump file systems are linear. there is a full order of system archives. in hg, there is a full order of the tip, but not so of branches in general. in git, multiple orders (not sure if they're full or not) can be imposed on a set of hashes. another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. - erik
