> Well, I guess I really got spoiled by ZFS's ability to do things like > $ zfs snapshot pool/projects/f...@yourtextgoeshere
at the console type "snap". if you're allowing snaps to be mounted on the local fs then the equivalent would be "mkdir /YourTextGoesHere; bind /n/dump/... / /YourTextGoesHere". note that zfs restricts where the snapshot can be mounted :p venti snapshots are, by default, read only. > $ zfs clone pool/projects/f...@yourtextgoeshere pool/projects/branch that's as simple as starting a new fossil with -f 'somehex', where "somehex" is the score of the corresponding snap. this gives you both read-only snapshots, and as many clones as you wish. note that you're cheating here, and by quite a bit: - snapshots are read only and generally unmountable (unless you go through the effort of making them so by setting a special option, which i'm not sure is per-snapshot) - clones can only be created off of snapshots - clones are read-writable but they can only be mounted within the /pool/fs/branch hierarchy. if you want to share them you need to explicitly adjust a lot of zfs settings such as 'sharenfs' and so on; - none of this can be done remotely - libzfs has an unpublished interface, so if one wants to, say, write a 9p server to expose zfs functionality to remote hosts they must either reverse engineer libzfs or use other means. so, while i'm sure you enjoy zfs quite a bit, for others used to plan9's venti/fossil way of doing things zfs can be quite a pain.
