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

Reply via email to