Макет хранилища Subversion для библиотек, разработанных для разных программ - PullRequest
13 голосов
/ 13 октября 2008

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

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

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

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

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

Я думал что-то вроде:

  • Библиотеки
    • Библиотека1 (предок)
    • Библиотека2 (предок)
  • Program1
    • Код программы1
    • Библиотека1 (филиал поставщика)
    • Библиотека2 (филиал поставщика)
  • ...

Затем, скажите, что при разработке Программы1 были сделаны некоторые изменения для Библиотеки2, я объединяю их обратно в часть Библиотеки хранилища и при желании объединяю их оттуда со всеми другими программами.

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

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

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

Ответы [ 2 ]

9 голосов
/ 13 октября 2008

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

Создайте свои библиотечные репозитории:

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"
1 голос
/ 13 октября 2008

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

...