thinking about the idea of a revision control file system brings me back to some work i followed by brian stuart. his θfs has a object store. the object store allows arbitrary metadata and object size. the ℙ snapshot device could be modified to take snapshots based on an arbitrary reference point, rather than "the last" snapshot. so in theory all the bits are there, they would just need to be put together in a different way. fun little thing to think about.
in any event, back to the subject at hand. this in-depth discussion of various revision control systems seems to assume that revision control is the key issue. i have seen plan 9-derived projects fail using codereview and google code because there wasn't a shared goal. so i would identify it as the key issue the goal is strategy, revision control is tactics. instead of a goal or vision, perhaps values are more down to earth. for example, a common value for kernel folks is "never break user land". let me propose this draft. 1. keep with the original value system of plan 9: e.g. simple implementation of advanced techniques, self-contained, avoid configuration, use mechanism such as namespaces instead. 2. run on as many systems as practical. do not break compatability without specific articulated reasons. 3. all changes are up for debate, but there is a clear path to decision making. - erik
