Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
78 lines (56 sloc) 2.96 KB
== What OCaml fuse binding to use?
libfuse-ocaml uses fuse_lowlevel_ops, inode-based, rather than fuse_operations,
path-based. Inodes are created by fs_mknod, and info is mapped from inode
to a more complete structure.
ocamlfuse uses the highlevel ops. Inodes are managed by fuse (unless you pass
use_ino). All ops take a path, and some file ops have state passed around
via fuse's fh (filehandle). fh is created when returning from open or create.
HL/LL differences explained:
Both bindings require build fixes; libfuse-ocaml had a bogus META and other
stuff fixed. ocamlfuse isn't findlib-compatible. Let's see which are
upstreamed first.
libfuse-ocaml is LGPL3+ with linking exception.
ocamlfuse is GPL2=.
== How to access and cache git data?
Data is accessed by path or inode, depending on the binding.
FileHandles are for rare cases with the high-level binding.
Tree data can be gotten in one pass for the entire tree,
in one pass for a node's children, or in one pass for just one item.
It's not possible to get tree node and tree children at once.
Depending on the strategy, we can end up with data cached with different
keys. The keys are either:
* tree root, tree path
* tree parent, child name
The first strategy is slightly wasteful in the case of subtree merges,
since it will ask again for things cached at a different path. That can also
happen in the not very likely case of access through /tree/hash paths for
a non-worktree-root hash.
The second is more expensive in case of subdirectory access when
the parents aren't cached, because it must hit the parent directories
first to find a key.
The first needs a full path which requires the high-level binding or some
multimap cache of inode->path (more memory).
The second can work with both bindings, assuming a map cache of inode->hash
for the low-level binding.
(nb: consider making inode<->hash bijective.
caveat: that will look like directory hardlinks.)
== How to bypass the command-line git api?
This api costs, in terms of fork/malloc/die and a few impedance mismatches.
libgit.a isn't stable, but we could use it.
We still have to be careful what we used (globals, leaks).
Consider killing it periodically so that memory won't grow.
I believe cgit has more useable stuff on top of libgit.a .
libgit2 might be useful someday,
but it is currently very skeletal.
A fast-import parser to memory structures could also work, but costs
memory as opposed to a library using zero-copy.
== Do we support refs not starting with refs/ ?
Those can be created by editing $GIT_DIR/packed-refs.
They work nearly everywhere,
* check-ref-format accepts them
* show-ref --verify refuses them
Since they are refused in at least one place -> consider not supporting them.
That means we get to collapse the fs/refs/ hierarchy to one level shallower.