[sugar] GVFS, OLPC, and GIT ?

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Larsson wrote:
| On Mon, 2008-03-24 at 15:34 -0400, Benjamin M. Schwartz wrote:
|> Dear Mr. Larsson,
|> My name is Ben Schwartz, and I am a volunteer with OLPC.  As you may be
|> aware, the OLPC design calls for a centralized versioning differential
|> datastore, in which all of the user's work is kept.  The versioning
|> requirements are similar to the capabilities of git, so git, or a
|> similar version control system, might be used as the backend.
|>
|> In addition to versioning, OLPC also requires that objects in the
|> datastore support extensive metadata for tagging and commenting.
|>
|> Would GVFS be an appropriate layer in which to implement generic access
|> to a version-controlled storage system like git?  In my perusal of the
|> GIO API docs, it was not clear to me that GIO's notion of a file is
|> sufficiently generic to encompass multiple versions.  I do not fully
|> grasp the layering between GIO and GVFS.
|
| GIO is the API. It is used by applications to access, enumerate and get
| info about files. It models the filesystem as an abstract entity that
| has a behaviour somewhat similar to posix, but more generic, with some
| extended operations (copy file, save, etc), and with somewhat less
| strict semantics. It contains an implementation of this for local files,
| but also allows plugins to extend this functionallity.
|
| GVfs is a plugin for gvfs that allows support for access to non-local
| files. This is achieved by a model where each "mount" of a remote (or
| otherwise virtutal) location is handled by a daemon. The gio plugin uses
| dbus to inititate operations with the daemon. GVfs also contains a set
| of backend daemons for different types of mounts (ftp, dav, sftp, etc).
|
|> What would you do, if you were trying to provide a version-controlled
|> datastore as a desktop service?
|
| The gio file model is somewhat generic. For instance file metadata are
| namespaced key-value pairs that you can extend however you want, and the
| backing of your filesystem can be whatever. However, it doesn't really
| have explicit versioning support. So, reading files from the latest or a
| particular snapshot in history of a versioned filesystem is handled
| fine, but the actual operations related to versions are not naturally
| expressed.
|
| However, it certainly can be done in a variety of ways. Some options off
| the top of my head are:
|
| * Mount the specific tree version you want (or HEAD to follow latest) as
| a separate mount (off the same backing version store)
|
| * Have some kind of operation that takes a versioned filesystem mount
| (globally) to a different version.
|
| * Expose multiple versions of the same file/directory using different
| names. For example each directory could have a ".history" subdirectory
| with files like .history/?<filename>/<version> which is a historic
| version of <filename>.
|
| What kind of user interface are you expecting to have for this? A
| timeline/time-machine kind of browser, or a per-file open-old-version
| kind of thing?

The desired UI is something like this:
http://wiki.laptop.org/go/Designs/Journal
There are large number of different, independently revision-controlled
directories, but the user can select any item and look through previous
versions of it.  I think there are also plans for a more detailed
time-line exploration view, but I do not know if any details have been
drawn yet.

It sounds like in order to use GVFS for a revision-controlled system, one
must either represent versions as paths or mounts.  Neither seems ideal to
me, as versions are something else altogether.

- --Ben

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6Qw/UJT6e6HFtqQRAtcGAKCSr4WQmfMSxiuHkRezkdDGe2rBEQCeKa+8
fnWEU36rSJkHvN4/RIZWzws=
=Tote
-----END PGP SIGNATURE-----