Каков наилучший способ работы с вложенными рабочими копиями svn в рабочей копии из одного и того же хранилища подрывников?

Моя команда поддерживает единый многопроектный репозиторий подрывной деятельности нашего исходного кода PHP. У нас есть простая стратегия развертывания, в которой библиотеки, используемые приложениями, хранятся в структуре каталогов. Это делает возможным развертывание с использованием либо tarball, либо путем проверки кода из подрывной деятельности. Это все работает хорошо, но в роли администратора в прошлом я сказал svn пользователям не создавать вложенные рабочие копии или не перестраивать дерево кода, особенно в рабочей копии, ведущей голову ветки соединительной линии.

У нас есть более сложный репозиторий, но важными являются следующие:

trunk/app4/libs/libB
trunk/lib1

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

parent_dir/
 app4/libs/libB
 lib1/

но для нашего delpoyment нам нужно структурировать дерево кода следующим образом:

app4/
 libs/
 lib1
 libB

Я использовал следующие шаги, чтобы установить это. # svn co svn://svn.example.com/trunk/app4./# cd app4/libs # svn co ssvn://svn.example.com/trunk/lib1

В результате каталог lib1 не включен в часть приложения 1 рабочей копии, что делает статус app1 нечистым, но является корнем его собственной рабочей копии. Это делает статус svn рабочей копии app1 нечистым, потому что каталог lib1 является новым файлом в рабочей копии app4.

# svn status

возвращается

? lib1

Это хорошая идея, чтобы очистить это, добавив Could я svn добавить каталог lib1 из app1/libs? Можно надеяться, что это добавит каталог p1/libs/lib1 в информацию svn для app1 без каких-либо изменений в app1/libs/lib1/.svn/, но я думаю, что это очень маловероятно. (TODO: проверьте это в примере)

Лучше ли просто лично игнорировать этот статус или, возможно, добавить libs/lib1, чтобы игнорировать, чтобы получить чистый статус? Какие еще варианты?

2 ответа

Правильное решение состоит в том, чтобы создать 2 рабочих копии.

app4_prj/
 app4/
 libs/
 lib1

lib1_prj
 app4/
 libs/
 lib1

В обоих:

# cd app4/libs 
# svn ignore lib1

Разработайте на lib1 и app4 в своих проектах. Таким образом, когда каждый проект проверяется, рабочие копии имеют чистый статус, lib1 не дублируется в svn, и вы можете более легко тестировать и возиться с lib и включать изменения от других членов команды при продолжении разработки приложения,


Вы не можете изменить точку монтирования репо-узлов, используя только рабочую копию (относительно lib1). Необходимо создать и использовать новый репозиторий (с внешними)

licensed under cc by-sa 3.0 with attribution.