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

Question

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

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

• Program1
  • Library1
  • Library2
• Program2
  • Library1
  • Library2

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

Так что я думал, что обрабатывать свои библиотеки на всех, кроме одного места, как vendor branches, но я не уверен, какой будет лучший макет для этого.

я что-то вдоль линий мышления:

• библиотек
  • Library1 (предок)
  • Library2 (предок)
• Program1
  • Program1 кода
  • Library1 (поставщик филиал)
  • Library2 (поставщик филиал)
• ...

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

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

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

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

Answer 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 и совершение коммитов в корне из этих проектов не влияет на библиотеки ... но, если вам нужно внести изменения в библиотеки, вы можете. Тогда тогда и только тогда, когда у вас есть права на запись в репозитории библиотеки, вы также можете зафиксировать эти изменения, но только из подкаталога библиотеки.

I.e. это не делает коммит к библиотекам ...

... 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" 

Answer 2

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