Re: [PATCH v5 25/27] refs: add LMDB refs storage backend

On Thu, Feb 25, 2016 at 3:43 AM, David Turner [off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

I'm not sure I get this comment. D/F conflicts are no longer
a
thing
for lmdb backend, right?

I'm trying to avoid the lmdb backend creating a set of refs
that
the
files backend can't handle.  This would make collaboration with
other
versions of git more difficult.

It already is. If you create refs "foo" and "FOO" on case
sensitive
file system and clone it on a case-insensitive one, you face the
same
problem. We may have an optional configuration knob to prevent
incompatibilities with files backend, but I think that should be
done
(and enforced if necessary) outside backends.

Sure, the current state isn't perfect, but why make it worse?

I see it from a different angle. The current state isn't perfect, but
we will be moving to a better future where "files" backend may
eventually be deprecated. Why hold back?

But this line of reasoning only works if we have a new backend
capable
of replacing "files" without regressions or introducing new
dependency. Which is why I suggest a new backend [1] (or implement
Shawn's RefTree if it's proven as good with small repos)

I have no problem if you want to stay strictly compatible with
"files"
though.

[1] http://thread.gmane.org/gmane.comp.version-control.git/285893/foc
us=286654

Won't RefTree have the same d/f conflict issue?

It's trees all the way down if I understand it correctly, so yes
RefTree should have d/f conflict issue as well.
-- 
Duy