Рекомендуется ли Git для больших (> 250 ГБ) хранилищ контента
Веб-приложение представляет собой настраиваемую CMS, которая имеет несколько подзадач, и каждый из них имеет код и контент, находящиеся в одной и той же структуре каталогов. Из-за архитектуры структуры приложения код и контент переплетаются (контент зависит от кода его отображения и других функций) и, следовательно, неотделимы. Содержимое не хранится как BLOB, а хранится как файлы, а базовая БД используется для их связывания. Размер суб-приложений варьируется от 20 ГБ до 250 ГБ и более (это убийца).
В веб-приложении появятся некоторые улучшения в коде (новые подзадачи, исправления ошибок и т.д.), и в то же время пользователи будут добавлять/обновлять содержимое через уже действующую систему. Следовательно, требуется процесс развертывания/выпуска, и, самое главное, система управления версиями должна предлагаться как для кода, так и для контента.
Git приходит к картине из-за причин - она открыта и свободна, легкость разветвления и слияния, ее не централизована и, следовательно, не имеет единственной точки отказа.
НО после некоторых начальных исследований в Интернете я обнаружил некоторые неутешительные факты, которые применимы к нашему приложению - использование Git для больших систем, таких как наша, является болезненным (checkout, clone, merge, push, pull), а команды сложный ( "geeky" был бы более уместным) для базы разработчиков, которая является DVCS неосведомленной и в основном пользователями Windows.
Нет никакого фиксированного мышления для Git, но если мне нужно пойти на централизованный подход (в самом деле на самом деле WORST), то каким должен быть способ (CVS и SVN в отдельности). Я читал о том, что Perforce является стабильным, и он также используется в Google (я ожидаю, что здесь есть некоторые удары!).
Просьба поделиться, просмотреть и прокомментировать свои мнения. Я действительно требую их.
Ответы
Ответ 1
Я просто случайно прочитал этот пост в блоге не одну минуту назад. Это немного рассказать о масштабируемости git.
Изменить: восемь лет спустя и Git имеет большое файловое хранилище (LFS), а Microsoft - открытый источник Git Виртуальная файловая система (GVFS), чтобы они могли использовать Git для разработки Windows.
Ответ 2
Во-первых, я не согласен с тем, что Git не подходит для нетехнических пользователей. Да, есть некоторые функции, которые новички не будут использовать (например, git -send-email). Но есть также GUI, такие как TortoiseGit, чтобы упростить простые вещи.
Однако, я думаю, вы приближаетесь к тому, что неправильно. В принципе, у вас есть контент, который будет часто меняться и должен быть легко доступен для редактирования Joe Bloggs, а код, который будет изменяться менее часто с помощью кодеров. Традиционным решением является использование реальной CMS (например, Alfresco, SugarCRM, Drupal и т.д. или Wiki (MediaWiki, MoinMon и т.д.) с дополнительными плагинами. Имейте в виду, вики (и большинство CMS) разрешить управление версиями содержимого "удобным" способом.
Даже если вы должны сохранить свой внутренний код, я думаю, вам все равно нужно выпустить контент, чтобы их можно было рассматривать отдельно. После того, как вы разделите код и контент, ваш репозиторий будет более разумным. Затем вы можете использовать любой VCS, который вам нужен (хотя я не уверен, что вы правы, что Git по своей сути плохо для больших репозиториев).
Ответ 3
git не масштабируется для больших репозиториев. Это не пространство, это количество файлов. Пожалуйста, прочитайте мою статью статью в блоге, о которой я уже писал об этом.
По моему опыту, если вы хотите масштабируемую, быструю централизованную систему управления версиями, P4 - это путь.
Ответ 4
Действительно ли SVN такой плохой вариант?
ПЛЮСЫ:
- Может обрабатывать большие репозитории, например. многие дистрибутивы Linux используют его, также Apache, Sourceforge
- Хороший интерфейс GUI с TortoiseSVN, чтобы ваши пользователи были довольны
- Может использоваться с встроенной аутентификацией Windows, чтобы поддерживать админов счастливыми.
- В зависимости от ваших требований могут быть приняты различные стратегии резервного копирования (svnadmin hotcopy или dump, svnsync, post-commit hooks), чтобы облегчить вашу проблему с одной точкой отказа.
МИНУСЫ:
Отказ от ответственности: я никогда не использовал Perforce и был счастливым администратором и пользователем SVN в течение ~ 6 лет (начиная с v0.29)
Ответ 5
Там утилита script называется git-split, которая отбрасывает репозиторий git, чтобы сделать его более эффективным.
Ответ 6
Microsoft только что выпустила Git Virtual File System (GVFS) специально для обработки большой базы кода с помощью git. Подробнее здесь, в msdn
Также Microsoft размещает источник Windows в чудовищном 300GB Git репозитории
У меня нет опыта использования GVFS.
Ответ 7
Я использовал git только один раз для школьного проекта (php-сайт с Zend Framework).
Мы использовали git, но учитель должен был иметь окончательный выпуск в репозитории svn.
Сравнение размера проверки:
git проверка была в два раза меньше, чем у MB svn checkout.
Мои два цента.