SVN: освободить ветвь и внешние?

У нас есть два веб-сайта для одного и того же клиента (главный сайт www и другой для сайта электронной коммерции, который находится на отдельном сервере), которые используют общую часть кода (различные функции/стили/javascript и т.д.). В настоящее время мы управляем этим, предоставляя общий код в виде отдельных проектов (в тех же репозиториях) в SVN и используя svn: externals, чтобы потянуть ветвь каждого из них в два проекта веб-сайта.

Мы только что создали две ветки релиза, по одному для двух сайтов. Все становится привязанным к сундуку для каждого из сайтов, как обычно при работе, и когда "готово для жизни" мы объединяем его в ветку релиза для этого сайта. Работает с удовольствием, за исключением того, что сегодня мы модифицировали часть общего кода и заметили, что ветвь релиза сразу же ее удалила, когда мы сделали обновление в ветки релиза. Это не то, что мы хотели: (

Итак, любые идеи, как мы можем сгладить эту проблему. Мы использовали externals для СУХОГО совместного использования кода, но есть ли другой способ? Обратите внимание, что в этом вопросе (Как я могу входить в SVN и иметь ветвь моей svn: внешние папки?), они говорят, что внешние являются плохими, и мы должны использовать другой процесс сборки, но не упоминает, что это должно быть.

У нас есть CruiseControl.net, который работает с нашими сборками и очень хочет, чтобы этот орех был взломан. У кого-нибудь есть идеи относительно лучшего процесса?

Приветствия

Пит

ОБНОВЛЕНИЕ: Мы с тех пор перешли на использование Mercurial (Fogcreek Kiln) для нашего источника управления. Mercurial также имеет идею суб-репо, поэтому мы следовали этому маршруту и ​​с нашим проектом. Однако это связано с себестоимостью, разветвление становится очень трудным, так как это мечение и просто держать все в курсе. Наш последний метод состоит в том, чтобы объединить оба проекта в один репозиторий, включая все общие репозитории. Это дает нам один "мегапроект", который замедляет время клонирования (проверка в SVN), но мы делаем это так редко, что выгоды от необходимости иметь дело с субрепозициями делают его хорошо стоящим. Теперь мы используем функцию переключения/переключения, а не ветвления, что также значительно упрощает наше развитие.

Ответы

Ответ 1

Если я правильно понял, у вас есть что-то вроде следующей структуры:

  • project1
    • Ствол
      • библиотека (через svn:externals library svn://repo/library)
    • ветки
      • RELEASE1
        • библиотека (через svn:externals library svn://repo/library)
      • Release2
        • библиотека (через svn:externals library svn://repo/library)
  • project2
    • Ствол
      • библиотека (через svn:externals library svn://repo/library)
    • ветки
      • RELEASE1
        • библиотека (через svn:externals library svn://repo/library)
  • библиотека

Я предполагаю, что вы - настройки svn:externals on/project1/trunk to/library. Если вы затем объедините ревизию с помощью svn:externals to/project1/branches/release1 и обновите эту ветку, вы автоматически получите последнюю версию из библиотеки. По умолчанию svn: externals получит ревизию HEAD ссылки.

Вы можете определить svn:externals для ссылки на конкретную ревизию, например: svn:externals -r123 library svn://repo/library. Это означает, что внешняя ссылка всегда укажет на эту конкретную ревизию. Таким образом, вы можете безопасно использовать этот тип ссылки svn:externals в своей ветке выпуска, не опасаясь, что код общей библиотеки будет обновляться, если вы не измените вручную svn:externals

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

  • project1
    • Ствол
      • библиотека (через svn:externals library svn://repo/library/tags/version3)
    • ветки
      • RELEASE1
        • (через svn:externals library svn://repo/library/tags/version1)
      • Release2
        • (через svn:externals library svn://repo/library/tags/version2)
  • project2
    • Ствол
      • (через svn:externals library svn://repo/library/tags/version2)
    • ветки
      • RELEASE1
        • (через svn:externals library svn://repo/library/tags/version1)
  • библиотека
    • теги
      • version1
      • version2
      • Version3

Ответ 2

У другой стороны есть несколько хороших советов, но на самом деле он использует svn: externals как систему управления зависимостью бедных. Это делает хакерский анти-шаблон несколько эффективным для дисциплинированных.

Вы абсолютно правы, что svn: externals - это не путь.

Еще одна вещь, о которой стоит подумать, если вы останетесь на этом пути - если ваши svn-теги не являются атомарными (с помощью привязки pre-commit), вам нужно указать ревизию, а также тег.

В настоящее время я страдаю от шок от того, что унаследовал некоторые вещи .NET, заставляя меня так скучать. Я даже согласился на беспорядок из ant/ivy.

Вы можете проверить https://www.nuget.org/

Ответ 3

Вы можете сделать svn update --ignore-externals, если вы не хотите, чтобы внешние файлы обновлялись.

Ответ 4

Да, использование внешних ссылок, указывающих на конкретную ревизию или тег, - это путь. Вы можете легко найти это, просто прочитав руководство svn по внешним... RFD! также, всего около одной страницы...:)

http://svnbook.red-bean.com/en/1.0/ch07s03.html

Ответ 5

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

svn copy -parent

... к их соответствующей точке монтирования. un-revisionned externals используют ревизию, на которую вы хотите включить свою ветку; Исправленные внешние использовали свою указанную ревизию при копировании. svn: свойство externals должно быть удалено в новой ветке.

Некоторые скрипты (perl для меня) могут помочь автоматизировать это. Пинг меня, если вам нужна дополнительная информация об этом.