это Джек из CollabNet, Codesion Cloud Services. Во-первых, спасибо за то, что вы являетесь клиентом Codesion!
Вы описываете свою ситуацию в терминах "проектов", но это двусмысленный термин, и сама Subversion не имеет никакого представления об этом вообще. Реальное внимание здесь уделяется не Subversion, а вашим инструментам сборки и политике выпуска. Вам нужна конфигурация, которая лучше всего поддерживает то, что вы хотите сделать.
Например, все ли эти приложения и библиотеки выпускаются одновременно? Полностью самостоятельно? Какой-то микс? Этот ответ может измениться?
Если все они выпускаются одновременно, то важно как можно проще определить, какие версии каждого приложения были выпущены с какими версиями других приложений. Таким образом, отчеты об ошибках можно проверить, внедрить исправления и объединить все исправления согласованным и согласованным образом. Чтобы достичь этого, я бы не использовал бы структуру "/ app / {trunk, tags, branch}", предложенную несколькими, а скорее придерживался канонической
/trunk/app1
/trunk/app2
/tags/TAGNAME/app1
/tags/TAGNAME/app2
/branches/BRANCHNAME/app1
/branches/BRANCHNAME/app2
структура. Это позволяет вам разветвлять, маркировать и объединять все дерево, все приложения и библиотеки одной командой:
svn cp URL/trunk URL/tags/TAGNAME
С другой стороны, если эти вещи независимы, тогда вам лучше с
/app1/trunk
/app1/tags
/app1/branches
/app2/trunk
/app2/tags
/app2/branches
...
Таким образом, например, пометка одного приложения не влияет на другое.
В смешанном случае вы все равно можете добиться скоординированного ветвления (когда это уместно), но вам придется использовать ветвление изнутри вашей рабочей копии и, возможно, разреженные извлечения (если рабочие копии большие). Кроме того, вы можете пометить или разветвить весь репозиторий, даже если тег или ветвь не имеют значения для большинства из них: теги и ветви Subversion дешевы в хранении, и (если вы используете форму URL-to-URL-адреса "svn cp" ") дешево сделать; единственная причина не помечать вещи несвязанными тегами, это смущает людей. Но это довольно веская причина, поэтому смешанную модель лучше всего обрабатывать структурой «app / trunk», чтобы избежать путаницы.
Хорошие примеры подхода "/ app / trunk" можно найти в репозитории Apache Foundation. Все проекты Apache (включая сам Subversion) хранятся в одном хранилище Subversion. Там около 100 проектов, и хотя есть некоторые взаимозависимости, все они в значительной степени управляются независимо. Вы можете просмотреть этот гигантский репо (возможно, самый большой репозиторий Subversion в публичном мире), начиная с корня всех проектов ASF . На практике есть некоторое разнообразие, но один хороший пример - Сам Subversion .
Также стоит отметить: что касается Subversion, вы всегда можете изменить этот материал. «Теги» и «ветви» на самом деле просто копии; Вы можете изменять вещи так, как вам нравится, когда вам нравится. Но есть некоторые предостережения:
- Это запутает людей
- «Конфликты деревьев» (добавление, удаление, перемещение или переименование файлов или каталогов) могут сделать последующие объединения болезненными. Функция инструмента слияния - сохранить вашу работу. Все инструменты слияния в конечном итоге, для достаточно сложного слияния, возвращают решения людям; важный вопрос - сколько они могут получить право без этого. Древовидные конфликты приводят к тому, что текущая Subversion (1.6 или лучше) работает намного чаще, чем вам хотелось бы. Поэтому лучше не переставлять каталоги верхнего уровня, подобные этим, и быть готовым вмешаться и очиститься от любых слияний, пересекающих такие перестановки.