> > 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.
venti is going to be a difficult model. the objects in scm are typically arbitrarly sized, and have arbitrary metadata. θfs has this model for its object store. venti does not. > > 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. i don't know. this concern was addressed in the very first paper, and i have delt with some plan 9-based systems that did this, and didn't get it right. but it can be addressed without much trouble. just have the fs export em all. - erik
