SVN: лучший способ поделиться общим кодом между проектами - PullRequest
Новая
       16

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

8 голосов
/ 21 марта 2009

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

Есть несколько способов улучшить это, и я хотел бы получить отзывы. Я на Windows и недавно мигрировал в Subversion.

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

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

Ответы [ 8 ]

16 голосов
/ 21 марта 2009

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

Внешние определения в книге SVN

7 голосов
/ 21 марта 2009

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

например. с хранилищем вроде 

repo/site1
repo/site2
repo/commonPieces

Вы можете ввести свойство "svn: externals" на директориях site1 и site2, которое говорит: "commonPieces url-to-repo / commonPieces".

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

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

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

3 голосов
/ 21 марта 2009

Вы можете добавить определение svn: external , указывающее на репозиторий WordPress или создать свой собственный "настраиваемый репозиторий WordPress" с помощью используемых плагинов и настроек.

2 голосов
/ 21 марта 2009

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

1 голос
/ 21 марта 2009

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

Svn repo-v
         |-Websites--v
         |           |---One
         |           |---Two
         |-Wordpress-v
                     |---branch one
                     |---branch two

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

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

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

Магистральные - ядро - обмен сообщениями - Супер мощное приложение № 1 - Супер мощное приложение № 2 - Супер мощное приложение № 3

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

0 голосов
/ 21 марта 2009

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

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

К вашему сведению - мигрировал из SVN около 2 лет назад из-за проблем такого типа.

0 голосов
/ 21 марта 2009

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

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

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