Git рекомендуется для больших (> 250 ГБ) репозиториев контента - PullRequest
27 голосов
/ 16 июня 2009

Веб-приложение представляет собой пользовательскую CMS, которая имеет несколько подпрограмм, и каждое из них имеет код и контент, находящиеся в одной структуре каталогов. Из-за архитектуры платформы приложения код и контент взаимосвязаны (контент зависит от кода для его отображения и других функций) и, следовательно, неразделимы. Содержимое хранится не как BLOB, а как файлы, и для их связи используется базовая БД. Размер вложенных приложений варьируется от 20 до 250 ГБ и более (это убийца).

Веб-приложение пойдет на некоторые улучшения в коде (новые подпрограммы, исправления ошибок и т. Д.), И в то же время пользователи будут добавлять / обновлять содержимое через уже работающую систему. Следовательно, требуется процесс развертывания / выпуска и, что наиболее важно, должна быть предложена система контроля версий как для кода, так и для контента.

Git приходит к картине по причинам - он с открытым исходным кодом и свободен, простота ветвления и слияния, он не централизован и, следовательно, не имеет единой точки отказа.

НО после некоторого первоначального исследования в сети я обнаружил некоторые неутешительные факты, которые применимы к нашему приложению - использование Git для больших систем, таких как наша, является болезненным (извлечение, клонирование, объединение, push, pull), а команды сложными ( "geeky" было бы более уместно) для разработчиков, которые не знают DVCS и в основном для пользователей Windows.

Для Git не существует фиксированного мышления, но если мне нужно перейти к централизованному подходу (в самом деле ХОРОШЕМУ случае), то каким должен быть путь (кроме CVS и SVN). Я читал, что Perforce является стабильной и также используется в Google (я ожидаю, что некоторые ошибки здесь !!).

Пожалуйста, поделитесь, направьте и прокомментируйте свои взгляды. Я действительно нуждаюсь в них.

Ответы [ 7 ]

24 голосов
/ 16 июня 2009

Я только что прочитал это сообщение в блоге минуту назад. Это немного напыщенная речь о масштабируемости git.

Редактировать: Восемь лет спустя, и Git имеет Большое хранилище файлов (LFS), и Microsoft использует открытый источник Виртуальная файловая система Git (GVFS), поэтому они могут использовать git для разработки Окна.

16 голосов
/ 16 июня 2009

Во-первых, я не согласен, что Git не подходит для нетехнических пользователей. Да, есть определенные функции, которые новички не будут использовать (например, git-send-email). Но есть также графические интерфейсы, такие как TortoiseGit , чтобы сделать простые вещи простыми.

Тем не менее, я думаю, что вы подходите к вещам неправильно. По сути, у вас есть контент, который будет часто меняться и должен очень легко редактироваться Джо Блоггсом, и код, который будет реже изменяться программистами. Традиционное решение - использовать настоящую CMS (например, Alfresco , SugarCRM , Drupal и т. Д. Или Wiki ( MediaWiki , MoinMon и т. Д.) С дополнительными подключаемыми модулями. Имейте в виду, что вики (и большинство CMS) позволяют создавать версии контента "удобным для пользователя" способом.

Даже если вы должны хранить свой внутренний код, я думаю, вы все равно должны захотеть извлечь контент, чтобы его можно было обрабатывать отдельно. Как только вы разделите код и контент, ваш репозиторий станет более разумным. Затем вы можете использовать любую VCS, какую захотите (хотя я не совсем уверен, что вы правы, что Git изначально плох для больших репозиториев).

10 голосов
/ 18 июня 2009

git не масштабируется для больших репозиториев. Это не пространство, это количество файлов. Пожалуйста, прочитайте мою статью в блоге , которую я недавно писал об этом.

По моему опыту, если вам нужна масштабируемая, быстрая, централизованная система управления источниками, P4 - это путь.

8 голосов
/ 16 июня 2009

Действительно ли SVN такой плохой вариант?

ПЛЮСЫ:

  • Может работать с большими хранилищами, например многие дистрибутивы Linux используют его, в том числе Apache, Sourceforge
  • Имеет хороший графический интерфейс с TortoiseSVN, чтобы ваши пользователи Windows были довольны
  • Может использоваться с интегрированной аутентификацией Windows, чтобы администраторы были довольны
  • Многие различные стратегии резервного копирования могут быть приняты на основе ваших требований (svnadmin hotcopy или dump, svnsync, перехваты после фиксации), чтобы облегчить вашу единственную точку сбоя.

МИНУСЫ:

  • Централизованный VCS

Отказ от ответственности: я никогда не использовал Perforce и был счастливым администратором и пользователем SVN в течение ~ 6 лет (с версии v0.29)

4 голосов
/ 19 ноября 2009

Существует служебный скрипт под названием git-split , который измельчает репозиторий git для повышения его эффективности.

2 голосов
/ 07 февраля 2017

Microsoft только что выпустила Виртуальная файловая система Git (GVFS) специально для обработки большой базы кода с помощью git. Подробнее здесь: MSDN

Также Microsoft размещает исходный код Windows в чудовищном репозитории Git объемом 300 ГБ

У меня нет опыта использования GVFS.

0 голосов
/ 16 июня 2009

Я использовал git только один раз для школьного проекта (php сайт с Zend Framework).

Мы использовали git, но учитель должен был получить финальную версию репозитория SVN.

Сравнение размера кассы:

git checkout был вдвое меньше МБ svn checkout.

Мои два цента.

...