Chad,
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.
For those of us who have never had FV available, technical users have
used VC tools for important files forever (scripts, config files, etc),
and will continue to use VC for those purposes, even if FV is
implemented, as VC has decided advantages for these uses (history,
management, etc.). For the technical user, FV is primarily useful for
when editing documents where were never put under VC in the pre-FV
era. This is virtually identical to the usage for "naive" users. That
is, FV is highly useful for keeping multiple copies of documents under
active editing.
In order for an FV implementation to be useful for this stated purpose,
it must fulfill the following requirements:
(1) Clean interface for users. That is, one must NOT be presented with
a complete list of all versions unless explicitly asked for it, and it
should be simple to select a version based on some reasonable criteria
(date of creation/modification, version number, etc.)
(2) Simple way to decide if a file should be versioned or not. Either
automatically version all files (or none at all), or provide a mechanism
to turn FV on/off on a per-file or per-directory basis.
(3) Network-FS awareness. Without this, FV is severely limited. Given
my preconditions above (that is, the current usage pattern of us in the
non-FS world), limiting FV to those on the local system restricts its
usefulness to the point where it isn't worth the effort.
So, we have two scenarios for the implementation here:
(a) FV requires no special API, and all programs using the Filesystem
automatically have access to versions
(b) FV uses a new API, so versions are only available to applications
using the new API
For case (a), you are going to have to store the versions as files
_somewhere_, in which case you run into the "directory pollution"
problem I quote (if you store the versions next to the "current"
version), or the "where is my version" problem that you quote w/r/t
snapshots (if you store them elsewhere).
In case (b), you will have to re-write _all_ FS-access apps to make them
FV-aware, in the same manner work had to be done to make apps
ACL-aware. And, to get requirement (3) above, you have to modify the
network FS protocols to support the API calls.
Also, regardless of which implementation mechanism you use (a) or (b),
you will need some sort of tool to indicate which files are to be
versioned (to satisfy requirement (2) above), how many versions are to
be kept, and other FV administration utilities. These tools will all
need to be netFS-aware/usable.
Disk space consumption is NOT irrelevant. Else, why is there so much
concern around the ZFS compression project? Disk is NOT cheap - on the
desktop, yes, but I'm sorry, networked disk systems are not really
cheap, and tape archivers less so. Allocating several GB of disk space
per end-user is not uncommon, so 1000 users requires multi-terabyte
systems just for "normal" storage (i.e. no
backups/versions/snapshots/archives). Take a look at what a typical
system costs: $10+/GB for workgroup-level storage (Sun 3510FC class,
1-20TB), $30+/GB for nice mid-level SAN storage arrays (Sun 6920-class.
>10TB). If I have to increase my storage requirements 25-50% for FV,
most of which is unused versions, this is decidedly non-trivial
amounts. This applies as well to the 5-second snapshot proposal.
For source code, FV isn't really needed - the problem has already been
solved. If your particular VC/editor/IDE doesn't handle the problem
correctly, then switch. There are many VC and IDE combinations on all
platforms which provide a solution to the same problem FV solves.
Mercurial, RationalRose, BitKeeper, Git, and others on the VC side;
NetBeans, CodeWarrior, Visual Studio, and even Emacs can be configured
to handle the problem on the IDE side.
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
