Использование библиотек с контролем версий в проектах с управлением источниками - PullRequest
Новая
       29

Использование библиотек с контролем версий в проектах с управлением источниками

7 голосов
/ 03 июля 2010

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

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

Какова наилучшая практика при использовании компонентов, также находящихся под контролем исходного кода? Должен ли я включить «библиотечные проекты» в систему управления исходным кодом «основной проект»? Это вызовет проблемы?

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

Ответы [ 3 ]

5 голосов
/ 03 июля 2010

У вас есть два основных вида зависимостей:

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

Если, когда вы говорите: «Я использую этибиблиотеки в проекте ", вы имеете в виду, что вам нужны двоичные файлы для компиляции вашего проекта, тогда вы можете хранить указанные двоичные файлы во внешнем репозитории (то есть не в (D) VCS, как Mercurial, а в репозитории артефактов , как Nexus)

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

0 голосов
/ 03 июля 2010

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

Структура папок сторонних библиотек выглядит следующим образом: 

- General
  - Delphi
    - Components
      - LibX
        - LibX 9.2.1.3890
        - LibX 10.1.0.7151
      - LibY
        - LibY 3.6
        - LibY 5.1
    - Plugins

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

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

0 голосов
/ 03 июля 2010

По моему опыту, поддержание совместимости с библиотеками, которые вы пишете одновременно, значительно улучшено благодаря использованию карт экспорта для предоставления нескольких версий ваших интерфейсов клиентским программам.Лучший гид, которого я знаю, это Ульрих Дреппер http://people.redhat.com/drepper/dsohowto.pdf

...