SVN: выпуск веток и экстернов? - PullRequest
16 голосов
/ 02 февраля 2010

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

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

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

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

Приветствия

Пит

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

Ответы [ 5 ]

19 голосов
/ 11 февраля 2010

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

  • 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 на / project1 / trunk to / library. Если вы затем объедините ревизию с svn:externals в / project1 / branch / 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
3 голосов
/ 13 декабря 2010

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

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

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

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

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

1 голос
/ 12 февраля 2010

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

http://svnbook.red -bean.com / о / 1,0 / ch07s03.html

1 голос
/ 02 февраля 2010

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

0 голосов
/ 20 октября 2011

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

svn copy --parent

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

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

...