Re: [zfs-discuss] Re: A versioning FS
On Fri, 2006-10-06 at 00:07 -0700, Richard L. Hamilton wrote: Some people are making money on the concept, so I suppose there are those who perceive benefits: http://en.wikipedia.org/wiki/Rational_ClearCase (I dimly remember DSEE on the Apollos; ...) I used both fairly extensively. Much of the apollo DSEE team left HP to write ClearCase. Neither are versioning filesystems; instead, both are software configuration management systems which export a limited virtual filesystem interface. With such systems, versioning is not transparent but instead involves interaction with a CLI or GUI around checkout/checkin. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: A versioning FS
What would a version FS buy us that cron+ zfs snapshots doesn't? Some people are making money on the concept, so I suppose there are those who perceive benefits: http://en.wikipedia.org/wiki/Rational_ClearCase (I dimly remember DSEE on the Apollos; also some sort of versioning file type on (probably long-dead) Harris VOS real-time OS.) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: A versioning FS
ClearCase is a version control system, though — not the same as file versioning. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: A versioning FS
On Fri, Oct 06, 2006 at 09:18:16AM -0700, Anton B. Rang wrote: ClearCase is a version control system, though — not the same as file versioning. But they have a filesystem interface. Crucially, this involves additional interfaces. VC cannot be automatic. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: A versioning FS
I think our problem is that we look at FV from different angles. I look at it from the point of view of people who have NEVER used FV, and you look at it from the view of people who have ALWAYS used FV. That's certainly a part of it. It's interesting reading this discussion, as someone who used VMS heavily through about the mid-1980s then became a UNIX sysadmin. File versioning was one of the items I really missed. There are a lot of interesting use cases (walk away from terminal, come back, quit emacs, get prompted whether to save file -- go ahead, save it, use 'diff' to determine what changed, and then delete the newly written file version if the changes are unwanted). Directory pollution really turned out not to be an issue in practice, perhaps because the default version limit was relatively small (3 in VMS). It could be set per-file or (IIRC) per-directory. If someone didn't want versioning at all, they could just set their directory to use one version, and old versions simply didn't exist. Alternatively, to see just the most recent versions, ';' would refer to the most recent version, so 'dir ;' showed only the filenames and no old versions (going from memory here). Having a delimiter character really did help. On UNIX, we have '/', though POSIX prohibits, or at least highly discourages, its use. Mac OS X uses '/' to access named forks (aka named streams, aka extended attributes in the Solaris sense). If I do 'ls xyz' I see just xyz. If I do 'ls xyz/rsrc' and xyz has a 'resource fork' then I see that. No real reason why I couldn't do 'ls xyz/versions', or, preferably, 'ls -V' :-) and see versions. 'diff xyz xyz/-1' would diff xyz with its immediately preceding version; 'diff xyz xyz/2' with version 2. (This would be interesting to prototype and do some usability testing.) I agree that we want a clean interface, that versions should be optional, and that they should be exposed via the network. (My home directory is NFS-mounted.) While disk space is not irrelevant, quotas really help in the multi-user scenario. If someone is close to their limits, they can use 'purge' (VMS syntax) to remove old versions of their files, or delete specific versions. I don't agree that version control systems solve the same problem as file versioning. I don't want to check *every change* that I make into version control -- it makes the history unwieldy. At the same time, if I make a change that turns out to work really poorly, I'd like to revert to the previous code -- not necessary the code which is checked in. (I suspect there may be some versioning systems which allow intermediate versions to be deleted, and I just haven't used them, but this still seems complex compared to only checking in known-good code.) This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: A versioning FS
People are oriented to their files, not to snapshots. True, though with NetApp-style snapshots, it's not that difficult to translate 'src/file.c' to '.snapshot/hourly.0/src/file.c' and see what it was like an hour ago. I imagine that a syntax like '.snapshot/22:20/src/file.c' would also be easy to use. (On the other hand, zfs currently requires knowledge of where the file system is rooted, and knowledge of where the current directory is within that filesystem, which IMHO is somewhat confusing to users and requires far too much typing.) I don't have an answer to your question about how to find an earlier version of a file with snapshots, though given an intelligent file system, there's no reason why we couldn't have a '.version' pseudodirectory (or the like) which understood file changes and was virtually populated by analyzing differences in the snapshots. This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: A versioning FS
Versioning cannot be automated; taking periodic snapshots != capturing application state. But I think we have existence proofs of operating systems which do automate versioning. It's true that capturing a new version each time a file has been modified and closed may not be perfect, but if it works for 99% of user cases, that's good for almost everyone. We have a lot of 99% tools (even 'ls' is pretty useless in a ten-million-file directory). If we introduce a new API, users won't see the benefits because nobody is going to update all of vi, vim, emacs, rsync, ftp, sed, cat, cp This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: A versioning FS
On Oct 6, 2006, at 23:42, Anton B. Rang wrote:I don't agree that version control systems solve the same problem as file versioning. I don't want to check *every change* that I make into version control -- it makes the history unwieldy. At the same time, if I make a change that turns out to work really poorly, I'd like to revert to the previous code -- not necessary the code which is checked in. (I suspect there may be some versioning systems which allow intermediate versions to be deleted, and I just haven't used them, but this still seems complex compared to only checking in known-good code.) The use cases are somewhat different here. I would venture to say that a *personal* file versioning system needs to be thought of differently from a *group* co-ordination formal version control system. Of course there is a fair amount of overlap in both use cases particularly when you consider a global namespace and concurrent access problems as you can see in the cedar or plan9 systems (fossil/venti):http://portal.acm.org/citation.cfm?doid=42392.42398http://cm.bell-labs.com/plan9/And if we were to also consider dynamic linking and versioning for depracated functions, there's another whole level of parallel backwards compatibility interface problems that are become much easier to approach.While this is an FV discussion, I do believe that we need some sort of clearer distinction between FV, VC, DR, CDP, and Snapshotting structured around the usability cases and close/sync vs a forced version mark/branch .. there's too much confusion in this space often with conflicting goals misapplied to often solve similar problems..je ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
