Как управлять общими библиотеками?

Question

Каждый раз, когда я делаю проект, я разрабатываю несколько общих процедур / модулей / библиотек, которые, как я ожидаю, я буду использовать с другими проектами.

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

Пока все хорошо.

Теперь, когда я использую их в другом проекте, я неизбежно совершенствую их - добавляю новые функции / функции, исправляю ошибки, делаю их более общими и т. Д.

В этот момент у меня есть несколько проблем:

• Мне нужно сохранить изменения в модуле для кода, над которым я работаю
• Мне нужно сохранить те же самые изменения в центральном репозитории "module"
• Мне нужно убедиться, что обновленные модули доступны, но не используются автоматически в старых проектах, а иногда даже в существующих проектах, над которыми я уже работаю.

Как вам это удается? Чем отличаются эти проблемы, когда команды работают над различными модулями в разных проектах?

-Adam

Answer 1

Если вы используете Subversion для всех своих проектов, вы можете просто использовать svn:externals: это позволяет одному репозиторию ссылаться на другой репозиторий, опционально исправленный в определенной ревизии. Например,

svn://svn/shared
svn://svn/project1
  |- dir1
  |- dir2
  \- svn:externals "shared -r 3 svn://svn/shared"
svn://svn/project2
  |- dir3
  \- svn:externals "shared -r 5 svn://svn/shared"

Примените ваши изменения к svn://svn/shared и измените свойство svn:externals в отдельных проектах, когда вы будете готовы.

В противном случае, используя другие VCS, вы можете просто оставить несколько тегов на shared, по одному для каждого проекта, используя shared, указывая на версию, которую они используют. Продвиньте каждый тег к более поздним версиям, когда будете готовы. Это требует ручного обновления копии каждого проекта shared, хотя (единственное, что делает svn:externals приятным, это то, что это происходит автоматически).

Если вы разветвляете / разветвляетесь shared для каждого отдельного проекта ... ну, это может сработать, но для сохранения и объединения изменений требуется рабочая сила.

[Изменить]

Дополнительные ссылки:

См. Внешние определения в svn book для обучения и более подробную информацию о svn:externals и git-submodule tutorial для аналогичной функции в DVCS git .

Answer 2

Разумеется, используйте контроль версий, как сказал PersistenceOfVision, а также ведите ночные сборки, чтобы убедиться, что вы не сломаете старые проекты.

Answer 3

Выберите пакеты контроля версий программного обеспечения ...

Например:
SVN + TortoiseSVN - это наше текущее решение. (Бесплатно)
Некоторые предпочитают Visual Source Safe. (Не бесплатно)

Answer 4

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