Каков достоинства использовать различный VCS (Системы управления версиями), которые существуют для отслеживания проектов Drupal?

Наша установка основана на Subversion. У нас есть небольшое (менее 4) количество людей, которые могут вносить изменения в сайт, и мы рассматривали DVCS, подобную Git, но пришли к выводу, что это избыточно.

Мы тестируем наш модуль с помощью SimpleTest перед фиксацией каких-либо изменений, и мы проводим новые тесты, если мы добавили функцию, которая не охвачена. На мой взгляд, этот этап тестирования перед фиксацией изменения гораздо важнее, чем то, какую программу управления версиями вы решите использовать в конце.

Еще одна важная вещь, которую вы должны помнить при работе с этими программами, - это то, что вам не следует просто выполнять регулярную проверку для обновления кода на вашем рабочем сайте. В результате останется скрытый .svn или другие каталоги, в которых могут содержаться пароли и другие конфиденциальные данные.

Вместо этого вы должны удалить модуль из каталога sites / all / modules и svn export , чтобы получить чистую версию последнего кода.

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

Модуль Развертывание - это еще одна вещь, которую следует учитывать в зависимости от вашего рабочего процесса.

Здесь еще одна подрывная установка.

Базовая настройка:

• Мы отслеживаем ядро ​​Drupal и все добавленные модули / темы, каждый из которых мы используем, в их собственной папке в одной части нашего репозитория
  • У каждого из них есть одна подпапка 'drop', куда копируются новые версии, как только мы начинаем их использовать.
  • Затем мы фиксируем это как «удаленная версия 6.xy» - это ведет к локальной истории выпускных версий ядра Drupal или рассматриваемого модуля (дублирующей «официальную» историю cvs на drupal.org, но больше удобно искать / различать в случае проблем)
  • Затем мы создаем ветку для дропа, названную в честь версии (например, drupal-6.15, views-6.x-2.8) - обычно она будет использоваться как есть ( см. «внешние элементы» ниже), но также служит базой для пользовательских изменений модуля, если они нам нужны. Мы стараемся избегать изменений в основных или дополнительных модулях, но иногда нам нужно исправить ошибку, и мы не можем дождаться, пока исправление в конечном итоге не завершится в официальном выпуске. Итак, мы вносим наши изменения и фиксируем их в этой ветке. Как только появится новая версия, мы можем сравнить ее с нашей веткой и в конечном итоге повторно применить исправление к ветке с новыми версиями, если она еще не включает исправление. Таким образом, у нас есть полный и многократно используемый обзор всех версий ядра и модулей, которые мы используем в различных проектах, включая любые настройки, которые нам в конечном итоге понадобились.
• Для каждого из наших проектов (сайтов) мы создаем обычную иерархию ствола / веток / тегов SVN в другой части репозитория
  • Затем мы используем Subversions 'externals' определения для получения основной версии, а также всех дополнительных модулей, которые нам нужны из ветвей, описанных выше. Важным моментом здесь является то, что мы можем получить любую версию, которая нам нужна , поэтому некоторые сайты могут использовать специально исправленную версию модуля x, в то время как другие могут использовать предыдущую версию без исправлений, а третий использует самую последнюю и лучшую официальный релиз - нам не нужно отслеживать этот беспорядок, поскольку SVN может точно сказать нам, что используется, когда и где, в любое время!
  • Затем мы добавляем элементы, относящиеся к нашему проекту / сайту - файл (ы) настроек, файлы .htaccess, конкретные модули / темы проекта и т. Д.
  • Новая разработка происходит в магистрали
  • Как только мы достигаем точки выпуска, мы создать ветку выпуска и тег, который
  • Мы экспортируем этот тег на тестовые / промежуточные / действующие серверы по мере необходимости
  • Между тем, новая разработка может продолжаться в магистрали
  • Если нам нужно применить исправление к текущей версии выпуска , это происходит в ветке выпуска
  • Опять же, исправление фиксируется, помечается и, наконец, экспортируется и развертывается
  • Если исправление требуется в целом, оно объединяется обратно в магистраль, так что оно будет доступно в будущие версии в целом
  • Вспенить, промыть, повторить ...

Плюсы:

• В основном, довольно полный обзор всего, что когда-либо происходило с любым кодом в любом из наших проектов :)
• В особенности, возможность отслеживать и повторно использовать различные версии основных или дополнительных модулей в разных проекты, даже с произвольными пользовательскими изменениями, без создания неуправляемого беспорядка (когда, почему и где мы использовали это пользовательское однострочное исправление в pathauto, и когда, почему и где мы прекратили его использовать - на это ответят журналы SVN)
• Воспроизводимые развертывания - если что-то пойдет не так на производственном сервере, мы можем экспортировать точный набор кода, использованный там, со всеми одноразовыми исправлениями, настройками и «особенностями» на месте (очевидно, полезно только в сочетании с правильным резервным копированием базы данных;)

Минусы:

• Как легко видеть из описаний выше, такая настройка создает небольшие административные издержки при импорте новых версий ядра / модуля (и большей части время это даже кажется ненужным, поскольку применение специальных исправлений - редкая вещь)
• Широкое использование внешних определений, как это, делает операции обновления для локальной проверки немного более длительными
• Когда набор изменений подразумевает комбинацию изменений в обоих , сам проект и пользовательский модуль, импортированный через внешние компоненты, это не будет атомарная фиксация, так как они должны быть проверены отдельно!

Заключение:

Пока вам нужно управлять только несколькими проектами / сайтами, это может быть неэффективным, и вам может быть лучше зафиксировать и поддерживать всю настройку (ядро, вклад и пользовательские вещи) вместе взятые. в одном филиале.

Но я могу заверить, что если вам придется управлять 10 ++ проектами параллельно (некоторые на 5.x, некоторые на 6.x, все на разных уровнях обновления и / или настройки, часто повторно используя одни и те же настройки), возможность сказать, какой код используется, где именно - огромное облегчение!

PS: Перечитывая мою проповедь, становится очевидным, что она на самом деле не отвечает на ваш вопрос о достоинствах различных VCS по сравнению друг с другом - извините за это, но, возможно, это все равно поможет;)

С тех пор, как я задал этот вопрос, произошла довольно неожиданная разработка на фронте Drupal: они вроде бы выбрали замену CVS ! Ссылаясь на массовую поддержку сообщества и потребность в распределенной системе контроля версий, они, вероятно, перейдут на git.

Раньше я рассматривал и пропускал git из-за худшей документации и кроссплатформенной поддержки (по сравнению с Bazaar и Mercurial), но с тех пор они значительно улучшились в обеих областях, и теперь кажется, что это действительно хороший вариант, независимо от ваших обстоятельств. .

Поэтому, если вы планируете внести свой вклад в «основные» или дополнительные модули или написать свой собственный модуль для сообщества, я настоятельно рекомендую использовать git, поскольку он будет иметь наибольшую поддержку и пользователей в сообществе Drupal в будущем. По этой причине это, вероятно, хороший выбор, даже если вы просто отслеживаете свои собственные сайты.

Я бы проголосовал за git, если у вас много членов команды. Хотя документация Git по-прежнему ужасна, бесплатная книга http://progit.org и http://gitcasts.com позволяют легко узнать, как использовать. Поскольку он настолько независим, он позволяет легко работать над проектами в любом месте и в любое время (по сравнению с SVN).

И я говорю это как парень с большим опытом работы с SVN, чем с мерзавцем. Разработка движется в сторону git и от центральных систем, таких как SVN.

Лично мне нравится то, насколько легко можно переключаться между различными тестовыми версиями вашего сайта (используя ветки).

У Drupal нет никаких специфических требований по сравнению с любым другим общим источником программного обеспечения.

Вот Git/Mercurial против Subversion:

• Git (но также верно для Mercurial)
  • Окончания строк будут нормализованы (неважно, RL+LF или LF или... это будет сохранено как "возврат строки" и распаковано, как говорит формат ОС)
  • Единый файл. gitignore позволяет указать все файлы, которые вы хотели бы игнорировать
  • У вас не будет папки .svn в каждой из ваших папок (что вынуждает использовать функцию медленного экспорта или пользовательский пакет для их удаления)
  • Чрезвычайно простая локальная настройка.
    1. Скачайте Git и запустите командную строку
    2. Перейдите в папку вашего проекта
    3. git add . && git commit -m "My first commit"
    4. Готово, теперь вы можете изменять файлы и возвращаться к своему первому коммиту
  • Хорошо делиться кодом в OpenSource проекте через GitHub
  • Есть TortoiseGit под Windows, если вам нужен простой GUI (ценой некоторых расширенных возможностей), но его немного сложнее установить, чем TortoiseSVN
• Subversion (SVN)
  • Несколько проще создать свой собственный частный сервер
  • Имеет ToirtoiseSVN под Windows, если вам нужен простой графический интерфейс (за счет некоторых расширенных возможностей)
  • Четкий клиент/сервер: Это означает, что для использования клиента вам также придется держать сервер запущенным (возможно, на той же машине, что и клиент)
• Я не могу сказать много о Bazaar, поскольку не использовал его

Очевидно, что я предвзято отношусь к Git и Mercurial. Оба они более современные. Я лично предпочитаю Git, потому что:

• Он не требует Python
• Есть portable версия
• Он позволяет мне переписать историю

Тем не менее, вы должны отметить, что Mercurial недавно привлек внимание Google (для Google Code) и он несколько проще в изучении. Вы можете изучить Git по http://progit.org/book/ (первых 3 глав должно быть достаточно).

Что касается структуры папок проекта, я предлагаю вам поискать другие ответы. Помните о своей цели (например: тестирование, быстрое развертывание на различных машинах...), и создайте резервную копию вашего хранилища. Это означает копирование папки проекта в удаленное место для Git/Mercurial и копирование репозитория сервера Subversion для Subversion. Кроме того, все они имеют крючки, позволяющие запускать тесты перед фиксацией, и интерфейсы для систем отслеживания ошибок.

И последнее, но не менее важное: если вы используете в своем проекте другие библиотеки под контролем версий, учтите это! Git и Mercurial позволяют отслеживать Subversion репозиторий (через git-svn), а не наоборот. Mercurial также может отслеживать Git репозиторий, но не наоборот (пока). Отслеживание удаленного репозитория позволяет вам получить последнюю версию с журналом изменений удаленного исходного кода, который вы будете использовать. Это также позволяет вам изменять его.