Как управлять внешними зависимостями, которые постоянно изменяются - PullRequest
7 голосов
/ 07 октября 2008

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

Наша текущая конфигурация:

  • мы разрабатываем для Linux и Windows
  • Мы используем SVN для нашего собственного кода
  • внешние зависимости (boost, log4cpp и т. Д.) Не хранятся в svn. Вместо этого я помещаю их в ./extern (или c: \ extern на окнах). Я не хочу помещать их в наш репозиторий, потому что я не смогу обновить их таким образом. Некоторые из них постоянно обновляются.

Мои вопросы

  • Что делать, если мне нужно изменить внешний код? В настоящее время я создал папку в моем хранилище SVN с именем extern_hacks, и именно туда я положил измененный внешний код. Затем я связываю (или копирую в windows) файлы во внешнюю структуру каталогов. Это решение проблематично, так как трудно следить за копированием файлов, и очень трудно обновлять с svn, когда файлы находятся в двух репозиториях (мой для измененных файлов, а исходный репозиторий говорит sourceforge)

  • Как управлять версиями внешних зависимостей?

Мне интересно услышать, как другие решают эти проблемы. Спасибо.

Ответы [ 5 ]

6 голосов
/ 07 октября 2008

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

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

2 голосов
/ 07 октября 2008

Я не понимаю, почему вы говорите

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

Тебе действительно нужно

  1. включить внешние зависимости в ваш источник контроля и периодически обновлять их, а затем тестировать, тестировать.

  2. Координируйте процесс сборки с обновлениями для внешних зависимостей.

Если ваш код зависит от чего-то, то вам действительно нужно контролировать, когда он обновляется / модифицируется. Кодирование в пространстве, где эти зависимости могут обновляться в любое время, слишком болезненно, как вы, несомненно, узнаете. Я лично предпочитаю вариант 1.

1 голос
/ 07 октября 2008

Когда мне нужно было сделать что-то подобное, я добавил внешний источник как внешний, а затем применил к нему патч. Патч содержит мои модификации для внешнего источника. Итак, я на самом деле только контроль версий своих патчей. В большинстве случаев это работает, если во внешнем коде нет «драматических» изменений.

0 голосов
/ 08 октября 2008

Я бы с осторожностью отнесся к Maven, потому что:

  • это еще один репозиторий в системе, где у вас уже есть репозиторий с вашей текущей системой контроля версий;
  • it (Maven) основан на единственном «общем контроле версий», который есть у каждого разработчика, - файловой системе (что означает отсутствие метаданных или свойств, прикрепленных к файлу, отсутствие надлежащей истории с точки зрения того, кто что изменил и когда)

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

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

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

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

Если вам необходимо в какой-то момент сравнить взломанную версию с какой-либо официальной версией, вы просто извлечете из svn соответствующий «взломанный» номер версии, распакуете его и сравните с официальной (и хранимой извне) версией. (например, с winmerge)

0 голосов
/ 07 октября 2008

Рассматривали ли вы Maven ? Это система сборки, которая имеет отличную поддержку для управления зависимостями. Для каждого проекта вы можете указать необходимые зависимости в XML-файле как часть этого проекта. Внешние библиотеки хранятся в хранилище зависимостей (в нашем случае Artifactory ), это отдельно от вашей системы контроля версий и может быть просто сетевым диском. Также позволяет управлять различными версиями проектов.

...