Каков наилучший способ обработки ветвей ветвей поставщиков в SVN?

Итак, я уже знаком с этим:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html Каков наилучший способ обработки ветвей ветвей поставщиков в SVN?

Мой вопрос, как вы справляетесь ветвь поставщика, который имеет как стабильный релиз и альфа/бета-ветвь, которую вы хотите включить?

Итак, скажем, вы следуете оригинальному примеру из книги SVN. Вы бы:

SVN: // локальный/дома/СВН/поставщика/libcomplex/ток
СВН: //localhost/home/svn/vendor/libcomplex/1.0
SVN: // локальный/дом /svn/vendor/libcomplex/1.1 (такой же, как ток)

Теперь у вас есть две версии вашей собственной «известково» приложение:

известково (это, по существу ствол == известково 2,0)
известково -1.0 (опубликовано для публики)

Предположим, что calc-1.0 использует libcomplex 1.0 и calc (в багажнике) используется libcomplex 1.1, который все еще разрабатывается.

В libcomplex 1.0 есть ошибка, и выпущена новая версия для исправления этой ошибки: libcomplex 1.0.1. Составители libcomplex также включили это исправление в libcomplex 1.1.

Вы не готовы к выпуску calc 2.0, поэтому вам нужно интегрировать libcomplex 1.0.1 в свою ветку поставщика и затем обновить calc-1.0, чтобы сделать исправление ошибок.

Куда деваться?

Вы не можете поместить его в svn: // localhost/home/svn/vendor/libcomplex/current, так как 1.1 там живет.

Вы скопируете svn: //localhost/home/svn/vendor/libcomplex/1.0 в svn: //localhost/home/svn/vendor/libcomplex/1.0.1, а затем принесете новую версию? Таким образом, вы можете использовать svn для объединения diff между 1.0 и 1.0.1 в calc-1.0.

источник

2009-08-15 Amir Ebrahimi

Рекомендуемая практика - создать ветку для выпуска. Таким образом, не имеет значения, какие изменения вы делаете в багажнике в своих папках поставщиков. Затем вы можете обновить ветвь версии 1.0 с версией libcomplex версии 1.0.1, и это не повлияло бы на trunk (calc 2.0).

Это не сработает, если calc 1.0 и calc 2.0 живут бок о бок в одной ветке.

Следующее, что нужно сделать, - не иметь «тока». Просто обратитесь непосредственно к той версии, которую вы используете. например, оставьте свою структуру папок как:

vendor/libcomplex/1.0 
vendor/libcomplex/1.1 
vendor/libcomplex/1.0.1

и никогда не перезаписывайте эти файлы. Тогда calc 2.0 может ссылаться на версию 1.1 libcomplex, а calc 1.0 может ссылаться на 1.0.1.

Ваш последний вариант (и не рекомендуется) - использовать теги svn (см. complex tags). Они позволяют смешивать и сопоставлять версии, поэтому вы можете технически создать тег, чтобы представить выпуск патча вашего calc 1.0 со старой версией libcomplex.

источник

2009-08-15 05:36:34

В моем предыдущем примере у меня есть ветвь для моего выпуска: calc 1.0. Папки поставщика не содержатся под calc. Вы предполагаете, что/vendor также разветвлен? Чтобы быть ясным, вот пример, который я описываю: /vendor/libcomplex/ /calc/trunk/ /calc/branches/1.0/ Ваше предложение не использовать «текущий» и использовать структуры папок не позволит должным образом объединить изменения между версиями в багажник, тем самым побеждая цель. Вам нужна эта история изменений, чтобы разрешить слияние изменений в тулбар, где вы изменили исходный источник поставщика. –

Мой подход к работе, когда все, что вы делаете, это использование выпущенных версий. Если вы также изменяете источник, тогда может быть полезно обработать код поставщика как ваш собственный код (т. Е. Включить его в свою ветку соединительной линии, а не иметь поставщика как отдельную папку). Однако ваш подход имеет смысл. Создайте ветку vendor/libcomplex/1.0.1, объедините любые настройки и обновите выпуск calc 1.0, чтобы указать на vendor/libcomplex/1.0.1, затем отпустите calc 1.0.1. Всякий раз, когда libcomplex 1.1 готов, объедините настройки, постройте calc2.0, и вам хорошо идти. Багажник никогда не указывает на 1.0.1 –

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

Учитывая это, ответ на вопрос становится достаточно ясным. Чтобы выпустить 1.0, 1.1, а затем 1.0.1, у продавца предположительно есть ветвь для версий 1.0.x с ошибкой, продолжая работать с 1.1 и более поздними версиями на своей внешней линии. Наша ветка поставщика должна отразить эту настройку.

То есть нам также нужна ветка (внутри нашей ветви поставщика) для версий 1.0.x с ошибкой. Это должно быть создано из текущего в то время, когда оно содержало 1.0, и может иметь название current-1.0.x. Затем эту ветку можно обновить до версии 1.0.1, которая затем может быть помечена и скопирована в наше собственное дерево, как обычно.

источник

2012-02-17 05:56:32 user200783

Я работаю, как это с внешними библиотеками:

project/myProject/{branches,trunk} 
vendor/libcomplex/1.0 
vendor/libcomplex/1.0.1 
vendor/libcomplex/2.0.0 
mypatched-vendor/libcomplex/1.0 
mypatched-vendor/libcomplex/1.0.1 
mypatched-vendor/libcomplex/2.0.0

vendor/<lib>/<version> Где никогда не изменяется после импорта и mypatched-вендор начал с svn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version>.

Теперь разница vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0 должна дать вам патчи, которые будут объединены с только что импортированной версией 1.0.1.

Я, вероятно, в меньшинстве, но мне нравится svn:externals. Довольно много IDE не любят их, поэтому используйте их с осторожностью. Причина в этом. Теперь я могу отредактировать свой основной проект:

checkout project/myProject/trunk to myprj-trunk у вас проверка работает.

svn propedit svn:externals . 
# with 
libcomplex URLTO/mypatched-vendor/libcomplex/1.0

Когда я хочу протестировать новую версию lib, я просто редактирую это свойство в другое место и запускаю обновление. Это также приводит к тому, что я не случайно ничего передаю libcomplex части дерева, даже если я изменил некоторые файлы на WC. Я должен находиться под этим каталогом или специально фиксировать изменения там.

Теперь обновление, исправления, ветви моего проекта легко переносятся в новые версии libcomplex, не более, чем первоначальное слияние с mypathed-vendor. Все мои филиалы проекта нуждаются только в замене и тестировании. Также относительно легко получить библиотечные зависимости для моих проектов IMHO.

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

libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk

Один определенного недостаток в СВН: внешнеположенностях является то, что внешний URL должен быть доступны с теми же URI из всех проверки варианты вашего проекта.

Но используя внешние позволяет вашему держать Vendor репо отдельно от вашего проекта репо.

источник

2012-02-18 09:24:55 Manwe

Каков наилучший способ обработки ветвей ветвей поставщиков в SVN?

ответ

Смежные вопросы