Re: Yet another base64 patch

From: David A. Wheeler <dwheeler@dwheeler.com>
Date: Apr 17, 2005, 16:29 UTC
Message-ID: <42628EFD.3030509@dwheeler.com>
In-Reply-To: <Pine.LNX.4.21.0504171018410.30848-100000@iabervon.org>

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:

Show 18 quoted lines

> 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