Подтвердить что ты не робот

Рекомендуется ли Git для больших (> 250 ГБ) хранилищ контента

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

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

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

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

Нет никакого фиксированного мышления для Git, но если мне нужно пойти на централизованный подход (в самом деле на самом деле WORST), то каким должен быть способ (CVS и SVN в отдельности). Я читал о том, что Perforce является стабильным, и он также используется в Google (я ожидаю, что здесь есть некоторые удары!).

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

4b9b3361

Ответ 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), чтобы облегчить вашу проблему с одной точкой отказа.

МИНУСЫ:

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

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

Ответ 5

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

Ответ 7

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

Мы использовали git, но учитель должен был иметь окончательный выпуск в репозитории svn.

Сравнение размера проверки:

git проверка была в два раза меньше, чем у MB svn checkout.

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