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

Question

Я пытаюсь найти лучшую стратегию управления версиями для моего рабочего процесса с Drupal. У меня есть несколько сайтов на установку, и я уверен, что у меня будет отдельный репозиторий для каждого сайта. Насколько я знаю, VCS стоит рассмотреть:

• SVN
• Базар (бзр)
• Гит
• ртутный (рт.ст.)

Я знаю, как они соотносятся друг с другом в целом, но хочу узнать их достоинства / недостатки для Drupal. Если вы используете (или использовали) какой-либо из них для Drupal:

• Каковы ваши настройки?
• Что с выбранной вами VCS хорошо работает для управления проектами Drupal?
• Что нет?

Answer 1

Другая настройка Subversion здесь.

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

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

Плюсы:

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

Минусы:

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

Вывод:

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

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

---

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

Answer 2

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

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

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

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

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

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

Answer 3

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, если вам нужен простой графический интерфейс (за счет некоторых дополнительных функций), но его установка немного сложнее, чем TortoiseSVN
• Subversion ( SVN )
  • Несколько проще создать собственный сервер
  • Имеет ToirtoiseSVN в Windows, если вы хотите простой графический интерфейс (за счет некоторых дополнительных функций)
  • Очистить клиент / сервер: это означает, что вам также придется поддерживать работающий сервер (возможно, на том же компьютере, что и клиент), чтобы использовать клиент
• Я не могу много сказать о Базаре , поскольку я не использовал его

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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