SVN: Лучший способ поделиться общим кодом между проектами

Question

У меня есть несколько проектов веб-сайтов в одном хранилище, каждый из которых имеет копию WordPress. Обновление WordPress означает обновление всех папок проекта и сохранение избыточных копий. Это полезно для моих rsync-скриптов, которые синхронизируют всю папку. Он также дает мне полные рабочие локальные копии сайта.

Существует несколько способов улучшить это и получить некоторую обратную связь. Я нахожусь в Windows и недавно перешел в Subversion.

1. Создание символических ссылок на биты WordPress в каждой папке веб-сайта. Будет ли это задерживаться в Subversion и Apache. Любые недостатки?
2. Имейте одну папку WordPress и вставьте ее в другие соединительные линии веб-сайта. Я читал, что ветки дешевы, и поддерживается одна копия, но я не уверен, что разветвление должно выполняться через соединительные линии. Лично я считаю, что это лучший подход. Есть ли причина избежать этого?
3. Наконец, я мог бы сохранить текущую структуру и использовать сценарий для копирования по всем папкам веб-сайта.

Каков наилучший подход и есть ли альтернативные решения?

Answer 1

Один из вариантов заключается в том, чтобы разделить биты WordPress на отдельный репозиторий (поскольку это не является частью ваших проектов, это просто то, что вы используете для их создания), а затем используйте svn: externals для извлечения этого в свои проекты в правильных местах.

Externals Definitions in the SVN book

Answer 2

Вы можете добавить наведению svn:external определения к WordPress repository или создать свой собственный отдельный «настроенное WordPress Repository» с плагинами и настройками, которые вы используете.

Answer 3

Может быть, я просто используя Subversion неправильный путь, но наша структура папок выглядит следующим образом

Магистральные - Core - Сообщения - Супер Мощный Прикладной # 1 - Супер мощный Применение # 2 - Super Powerful Application # 3

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

Answer 4

Часто случается, что я повторно использую одни и те же библиотеки классов для разных проектов, и в моем случае я предпочитаю иметь отдельную скопированную копию для каждого проекта. Единственная причина в том, что я не хочу разорвать проекты, над которыми я не работал некоторое время, если одна из библиотек устареет. Однако, если каждый проект является частью своего рода основного проекта, вы постоянно работаете над тем, как он отличается.

Answer 5

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

Это имеет несколько преимуществ:

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

Answer 6

Традиционно все должно быть разделено на SVN. Похоже, вы используете SVN как средство для захвата кода из разных областей и сшивания их вместе.

Итак, вы используете SVN в качестве инструмента построения. Это лучше:

• держать ваши плагин отдельно
• не хранить сам WordPress в SVN, если вы не используете поставщик филиал
• , когда вам нужно захватить определенное приложение с конкретными компонентами, работать с строить-скрипт.

Answer 7

Если вы уже размещаете все сайты вместе в одном хранилище, svn: externals можно использовать для разных частей одного и того же репозитория.

E.g. с хранилищем как

 
repo/site1 
repo/site2 
repo/commonPieces 

Вы можете ввести «SVN: Externals» собственность на site2 и Сайта 1 директорий, который говорит «commonPieces URL-к-репо/commonPieces».

Вы, очевидно, захотите избежать каких-либо рекурсивных циклов. Но это имеет то преимущество, что все в одном репозитории и может обмениваться историей - вы можете тянуть вещи, которые становятся более распространенными с сайта1 или сайта2 в commonPieces, используя «svn copy».

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

---

Edit: это стоит помнить, что в то время как «обновление СВН» на Сайта 1 будет автоматически обновлять commonPieces с этим свойством «svn: externals» на месте, «svn commit» на сайте1 не будет показывать вещи, которые были изменены в site1/commonPieces. Вам нужно будет сделать две отдельные фиксации: одну с сайта1 и одну с сайта1/commonPieces.

Answer 8

Каков наилучший подход и существуют ли альтернативные решения?

Не идти от темы, но я предлагаю вам взять твердый взгляд на git. Мы делаем этот вид вещи изо дня в день с подмодулей, и это ветер.

FYI - перенесено из SVN около 2 лет назад из-за этих проблем.