What I most look forward to in libfossil is the potential to expose a
repository, including all its yummy history, into a Unix filesystem.
At work I use ClearCase (when forced), and it bothers me a lot. But it
does have one feature I use a bunch: mvfs. If I version /main/branch/5
of a file foo.c, I can access it as /repo/foo.c@@/main/branch/5 using
any program I like, for instance vim and diff, and I'm not limited to
using the rather pathetic tools that come with ClearCase for doing
merges and such.
I'd like something similar with Fossil, though completion of libfossil
is an obvious prerequisite. Putting libfossil and fuse together could
be the way to go.
Of course, it would also be necessary to devise a mapping between
filesystem names and Fossil. ClearCase's method of naming versions fits
the Unix filesystem reasonably well, but Fossil deviates significantly,
and for good reason. I'm not saying it's impossible, only that it will
take some thought.
Clearly, one way to go (can certainly support multiple simultaneously)
would be to let artifact IDs, or unambiguous prefixes thereof, map to
the artifacts. Whether this is only valid for checked-in files or also
for stuff like events and wiki and tickets, that's an open question, as
is what you get when you readdir(). The top level of the repository
directory should probably contain subdirectories indicating the naming
mechanism used within, for instance /repo/artifact/01234567 is how you
get artifact with prefix 01234567 from the repository mounted at /repo.
Ambiguous prefixes probably shouldn't be treated as nonexistent files,
since nonexistent files ought only to mean there's zero artifacts with
that prefix. Instead maybe make them directories containing all the
artifacts with the prefix.
How should different artifact types be distinguished? More directory
hierarchy, I'd imagine. And where would the metadata go? I dunno.
There are funny tricks where an object in the filesystem is both a file
(you can cat it) and a directory (you can ls it), though perhaps there
are better ways to go such as making the contents of the file be yet
another kind of metadata. Or we just draw the line and say that only
file data is exposed.
I should hope knowing the artifact IDs isn't the only way to get around.
Perhaps also have /repo/commit/VERSION/ be the root of a directory
tree containing all the files in the commit named by VERSION, which
could be an artifact ID or tag or date.
This needs a great deal more thought. I'm just trying to put out some
ideas to get us started.
This would be a great way to glue Fossil to scripts or diff or vimdiff
or whatever tools you like so you can simultaneously work with normal
files and old stuff that would otherwise be buried in the repository.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
