Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

[erik quanstrom <quanstro@quanstro.net>]

> 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