Макет репозитория Subversion для библиотек, разработанных в разных программах

Я отвечаю за несколько (довольно маленьких) программ, которые используют много кода через разные библиотеки. Мне интересно, какой лучший макет репозитория должен разрабатывать различные прорграммы (и библиотеки) и поддерживать синхронизацию библиотек во всех программах.

Для аргумента предположим, что есть две программы с двумя библиотеками:

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

Тогда скажем, при разработке Program1 некоторые изменения внесены для Library2, я объединю их обратно в часть Libraries в репозитории и объединим их оттуда ко всем другим программам по желанию.

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

Я немного обеспокоен тем, что через некоторое время произойдет много слияний и немного головной боли в обслуживании, но на самом деле я не вижу гораздо лучшего решения.

И снова это кажется довольно распространенным случаем для меня, поэтому я подумал, что просто попрошу сообщество stackoverflow, какой лучший макет репозитория достигнет этого?

Ответы

Ответ 1

Ну, я думаю, я не согласен с тем, что внешние вопросы не могут быть и речи. У меня была аналогичная проблема в прошлом. Я решил это, используя внешние свойства svn.

Создайте репозитории библиотеки:

svnadmin create /path/library1
svnadmin create /path/library2
...

Создание клиентских репозиториев:

svnadmin create /path/program1
svnadmin create /path/program2
...

Теперь объявите библиотеки внешними в репозиториях программы:

cd /path/program1
svn propset svn:externals "library1 svnpath://wherever/library1/trunk/" .
svn propset svn:externals "library2 svnpath://wherever2/library2/trunk/" .

Теперь вы можете вносить изменения в программы 1 и 2, а фиксация в корне этих проектов не влияет на библиотеки... но если вам нужно внести изменения в библиотеки, вы можете. Тогда тогда и только тогда, когда у вас есть права на запись в библиотечные репозитории, вы также можете зафиксировать эти изменения, но только из подкаталога библиотеки.

т.е. это не делает фиксацию для библиотек...

... make a change in /path/program1/library1 ... 
cd /path/program1
svn commit -m "some change"

Это совершает изменение, внесенное в библиотеку выше:

cd /path/program1/library1
svn commit -m "change to library code"

Ответ 2

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