Re: Yet another base64 patch

["David A. Wheeler" <dwheeler@dwheeler.com>]

I wrote:
>>>It's a trade-off, I know.

Paul Jackson replied:
>>So where do you recommend we make that trade-off?

Daniel Barkalow wrote:
> So why do we have to be consistant? It seems like we need a standard
> format for these reasons:
> 
>  - We use rsync to interact with remote repositories, and rsync won't
>    understand if they aren't organized the same way. But I'm working on
>    having everything go through git-specific code, which could understand
>    different layouts.
> 
>  - Everything that shares a local repository needs to understand the
>    format of that repository. But the filesystem constraints on the local
>    repository will be the same regardless of who is looking, so they'd all
>    expect the same format anyway.
> 
> So my idea is, once we're using git-smart transfer code (which can verify
> objects, etc.), add support for different implementations of 
> sha1_file_name suitable for different filesystems, and vary based either
> on a compile-time option or on a setting stored in the objects
> directory.

I think that's the perfect answer: make it a setting stored
in the objects directory (presumably set during
initialization of the directory), and handled automagically
by the tools.  I recommend handling them NOT be a compile-time option,
so that the same set of tools works everywhere automatically
(who wants to recompile tools just to work on a different file layout?).


> The only thing that matters is that repositories on
> non-special web servers have a standard format, because they'll be serving
> objects by URL, not by sha1.

If the "layout info" is stored in a standard location for a
given repository, then the rest doesn't matter. The library would just
download that, then know how to find the rest.

--- David A. Wheeler