Re: [PATCH v7 31/33] refs: add LMDB refs storage backend

On Tue, Mar 1, 2016 at 8:35 AM, David Turner [off-list ref] wrote:

On Tue, 2016-03-01 at 08:31 +0700, Duy Nguyen wrote:

quoted

On Tue, Mar 1, 2016 at 7:53 AM, David Turner <
dturner@twopensource.com> wrote:

quoted

+Weaknesses:
+-----------
+
+The reflog format is somewhat inefficient: a binary format could
store
+reflog date/time information in somewhat less space.

This raises an interesting question. What if we want to change lmdb
format in future (e.g. to address this weakness)? Do we need some
sort
of versioning in lmdb database? I suppose you can always add "lmdb2"
backend that shares most of the code with current lmdb backend. Not
sure if that's what you had in mind though.

The weakness of versioning inside the LMDB database is that in order to
check the version, you need to already have LMDB.  That's the argument
for "lmdb2".

I had sort of hoped that this version would be "good enough" that we
could avoid modifying it.  So maybe that means we ought to address the
reflog format.  But I'm not sure that it's that big a deal.  What do
you think?

I'm not using lmdb yet (can't because if I convert my git.git to use
it, all topics I'm working on must be rebased on lmdb :-( ) so I don't
have any strong opinion about this. As long as we have an escape hatch
(that won't lead to a too messy future) I think we're good.

Note that storing in binary also has disadvantage. If we move from
SHA-1 to SHA-XXX in future, we can easily detect incorrect reflog line
in text form, it's a bit harder to do in binary form when you pack
everything (including some variable stuff like email) in one value.
But I think we don't have to care about that right now, there will be
lots of problems migrating to SHA-XXX anyway.
-- 
Duy