Re: [PATCH v4 20/21] refs: add LMDB refs storage backend

On Mon, 2016-02-15 at 16:57 +0700, Duy Nguyen wrote:

On Sun, Feb 14, 2016 at 7:04 PM, Duy Nguyen [off-list ref]
wrote:

quoted

On Sat, Feb 6, 2016 at 2:44 AM, David Turner <
dturner@twopensource.com> wrote:

quoted

+static char *get_refdb_path(const char *base)
+{
+       static struct strbuf path_buf = STRBUF_INIT;
+       strbuf_reset(&path_buf);
+       strbuf_addf(&path_buf, "%s/refdb", base);
+       return path_buf.buf;
+}

...

quoted

+static int lmdb_init_db(struct strbuf *err, int shared)
+{
+       /*
+        * To create a db, all we need to do is make a directory
for
+        * it to live in; lmdb will do the rest.
+        */
+
+       if (!db_path)
+               db_path =
xstrdup(real_path(get_refdb_path(get_git_common_dir())));

This works for multiple worktrees. But scripts may have harder time
getting the path. The recommended way is "git rev-parse --git-path
refdb" but because "refdb" is not registered in
path.c:common_list[],
that command becomes git_path("refdb") instead of
get_refdb(get_git_... like here. And I will need to know that
.git/refdb is _not_ per-worktree when I migrate/convert main
worktree
(it's very likely I have to go that route to solve .git/config
issue
in multi worktree).

The solution is register refdb to common_list[] and you can do
git_path("refdb") here. But then what happens when another backend
is
added? Will the new backend use the same path "refdb", or say
"refdb.sqlite"? If all backends share the name "refdb", why can't
we
just reuse "refs" instead because the default filesystem-based
backend
is technically just another backend?

To answer myself: I forgot that there were per-worktree refs (e.g.
refs/bisect). It makes me wonder if we should put per-worktree refs
to
lmdb as well (maybe one per worktree if we don't want to put all in
one db). One of the advantages of moving away from fs-based backend
is
the ability to deal with case sensitivity, "nested" refs (e.g. a/b
and
a/b/c are both refs).

I don't think case-sensitivity is a huge problem here: per-worktree
refs are now HEAD or refs/bisect/*, and refs/bisect is controlled
entirely by the bisection machinery (that is, it won't have user
-defined refs with case conflicts).

 With this split, I think some refs are still
left behind.. Sorry if this was discussed before, I haven't followed
this closely.

Previous discussion:
http://comments.gmane.org/gmane.comp.version-control.git/275097