On Thu, 22 May 2014 08:45:48 EDT erik quanstrom <quans...@quanstro.net> wrote: > > 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.
I don't quite recall what I was thinking 3 years ago in a 30 minute window but I think the idea was that you have a set of configuration files which all need to be consistent and if you wanted to "roll back" changes, you'd have to undo all those changes. > > - 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. So if we do SCM right, backups are just a subset, right?! No, don't believe that. No time to explore this right now but I think dumps are at a different (lower) level from SCM data. > 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. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. > 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. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know.
