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
prev parent 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