Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Miles Bader <miles@gnu.org>
Cc: Pau Garcia i Quiles <pgquiles@elpauer.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: blobs (once more)
Date: Thu, 7 Apr 2011 08:45:56 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.1.00.1104070836590.2040@bonsai2> (raw)
In-Reply-To: <buo4o6abpsg.fsf@dhlpc061.dev.necel.com>

Hi,

On Thu, 7 Apr 2011, Miles Bader wrote:

> Pau Garcia i Quiles <pgquiles@elpauer.org> writes:
> > The usual answer to the "I need to put binaries in the repository" 
> > question has been "no, you do not". Well, we do. We are in heavy 
> > development now, therefore today's version may depend on a certain 
> > version of a third-party shared library (DLL) which we only can get in 
> > binary form, and tomorrow's version may depend on the next version of 
> > that library, and you cannot mix today's source with yesterday's 
> > third-party DLL. I. e. to be able to use the code from 7 days ago at 
> > 11.07 AM you need "git checkout" to "return" our source AND the 
> > binaries we were using back then. This is something ClearCase manages 
> > satisfactorily.
> 
> If it were me, I'd just store the huge binaries in some sort of separate 
> remote filesystem, and then store the remote-file-system _paths_ to them 
> in git (in a simple text file).

That fails for a number of reasons:

- it does not pass the 30,000-feet-high test

- integrity is not guaranteed (anybody can edit the files on the remote 
  file system, and nobody would realize that a "git checkout HEAD~2000" 
  ends up being something different from before)

- you would have to reinvent an efficient transfer (e.g. taking into 
  account all the data we have already)

- storage is no longer efficient, especially if you have multiple versions 
  of the same file.

- it is no longer decentralized anymore. Just think about yourself sitting 
  in the middle of antarctica, desperately needing to match a penguin 
  against a database of known penguins. You definitely want to have the 
  database local instead of leeching it down the non-existing wire all the 
  time. Likewise, if you and your group sit, say, on Viti Levu, and 
  develop software with people from New York, Texas, you definitely want
  a repository-in-the-middle, making it one person's duty to synchronize, 
  say, once per day.

I am sure you can think of more reasons.

Ciao,
Johannes

      reply	other threads:[~2011-04-07  6:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06  8:09 blobs (once more) Pau Garcia i Quiles
2011-04-06  9:25 ` Johannes Schindelin
2011-04-06 12:20   ` Michael J Gruber
2011-04-06 14:14   ` Martin Langhoff
2011-04-06 11:06 ` Matthieu Moy
2011-04-06 11:12   ` Peter Jönsson P
2011-04-06 16:42     ` Magnus Bäck
2011-04-07  5:20 ` Miles Bader
2011-04-07  6:45   ` Johannes Schindelin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.00.1104070836590.2040@bonsai2 \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=miles@gnu.org \
    --cc=pgquiles@elpauer.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox