Почему бы не использовать git для больших файлов? [Дубликат]
Вопрос был:
Как вернуть ответ от асинхронного вызова?
, который может быть интерпретирован как:
Как сделать синхронный асинхронный код синхронным?
Решение будет состоять в том, чтобы избежать обратных вызовов и использовать комбинацию Promises и async / await.
Я хотел бы привести пример для запроса Ajax.
(Хотя он может быть записан в Javascript, я предпочитаю писать его на Python и компилировать его в Javascript, используя Transcrypt . Это будет достаточно ясно.)
Позволяет сначала включить использование JQuery, чтобы
$был доступен какS:__pragma__ ('alias', 'S', '$')Определить функцию, которая возвращает Promise, в этом случае вызов Ajax:
def read(url: str): deferred = S.Deferred() S.ajax({'type': "POST", 'url': url, 'data': { }, 'success': lambda d: deferred.resolve(d), 'error': lambda e: deferred.reject(e) }) return deferred.promise()Использовать асинхронный код, как если бы он был синхронным:
async def readALot(): try: result1 = await read("url_1") result2 = await read("url_2") except Exception: console.warn("Reading a lot failed")
3 ответа
В принципе, это сводится к компромиссам.
В одном из ваших вопросов есть пример самого Линуса:
[...] CVS, т.е. он действительно заканчивается в значительной степени ориентированный на модель «один файл за раз».
Что приятно в том, что у вас может быть миллион файлов, а потом только проверить несколько из них - вы даже не сможете см. влияние других 999,995 файлов.
Git принципиально никогда не смотрит на меньшее, чем весь репо. Даже если вы немного ограничиваете (т.е. проверяете только часть или возвращаете историю немного), git заканчивается, все еще всегда заботясь обо всем, и неся знания вокруг.
Так что git весит очень плохо, если вы заставляете его смотреть на все как на один огромный репозиторий. Я не думаю, что эта часть действительно исправлена, хотя мы, вероятно, можем ее улучшить.
И да, тогда есть проблемы с «большим файлом». Я действительно не знаю, что делать с огромными файлами.
Так же, как вы не найдете структуру данных с доступом и вставкой O (1), вы не найдете трекер контента, который делает все фантастически.
Гит сознательно выбрал лучшее в некоторых вещах, в ущерб другим.
Использование диска
Поскольку Git - это DVCS (
У этого есть некоторая действительно Хорошие преимущества, поэтому DVCS, такие как Git, стали безумно популярными.
Однако репозиторий с 4 ТБ на центральном сервере с SVN или CVS управляем, тогда как если вы используете Git, все не будут в восторге с переносом этого.
Git имеет отличные механизмы для минимизации размера вашего репо, создавая дельта-цепочки («diffs») через файлы. Git не ограничивается путями или фиксирует заказы при их создании, и они действительно работают очень хорошо ... вроде как gzipping всего репо.
Git помещает все эти небольшие различия в packfiles. Цепочки Delta и packfiles заставляют извлекать объекты на некоторое время, но это очень эффективно для минимизации использования диска. (Есть снова эти компромиссы.)
Этот механизм не работает также для двоичных файлов, поскольку они имеют тенденцию отличаться совсем немного, даже после «малого» изменения.
История
Когда вы регистрируетесь в файле, вы имеете его навсегда и всегда. Ваши внуки внуков внуков будут загружать ваш кот gif каждый раз, когда они клонируют ваше репо.
Это, конечно, не уникально для git, поскольку DCVS делает последствия более значительными.
И хотя можно удалить файлы, дизайн контента на основе git (каждый идентификатор объекта является SHA его содержимого) делает удаление этих файлов сложным, инвазивным и разрушительным для истории. В отличие от этого, я могу удалить крутой двоичный файл из репозитория артефакта или ведра S3, не затрагивая остальную часть моего контента.
Сложность
Работа с действительно большими файлами требует много тщательной работы, чтобы убедиться, что вы минимизируете свои операции и никогда не загружаете все это в память. Это очень сложно сделать надежно при создании программы с таким сложным набором функций, как git.
Заключение
В конечном счете разработчики, которые говорят «не ставьте большие файлы в Git "немного похожи на тех, кто говорит« не помещайте большие файлы в базы данных ». Им это не нравится, но любые альтернативы имеют недостатки (Git intergration в одном случае, соответствие ACID и FKs с другим). В действительности, он обычно работает нормально, особенно если у вас достаточно памяти.
Он просто не работает, как и с тем, для чего он был предназначен.
Это потому, что каждая проверка хранит каждую версию каждого файла.
Теперь есть способы, позволяющие смягчить эту проблему, например бинарные различия и разреженные клоны, но, конечно, каждый клиент будет иметь как минимум две копии ( один в дереве работ, один в репозитории) каждого файла. Независимо от того, является ли это проблемой для , вы зависят от ваших обстоятельств.
Неверно, что git «не может обрабатывать» большие файлы. Просто вы, вероятно, не хотите хотеть использовать git для управления хранилищем больших двоичных файлов, потому что git repo содержит полную историю каждого файла, а дельта-сжатие гораздо менее эффективно для большинства видов бинарных файлов, чем в текстовых файлах. Результатом является очень большое репо, которое требует много времени для клонирования, использует много дискового пространства и может быть неприемлемо медленным для других операций из-за большого количества данных, которые он должен пройти.
Альтернативы и дополнения, такие как git-app, хранят изменения больших двоичных файлов отдельно, таким образом, что нарушает обычное предположение git о наличии каждого предыдущего состояния репозитория, доступного в автономном режиме в любое время, но избегает для отправки таких больших объемов данных.