У меня есть проект, созданный для нескольких ОС (сейчас Linux и Windows, может быть OS X) и процессоров. В этом проекте у меня есть несколько библиотечных зависимостей, которые являются внешне мужскими, но у меня есть пара внутренних, в исходной форме, которые я компилирую (кросс-компиляцию) для каждой комбинации ОС-процессора, возможной в моем контексте.
Большинство внешних библиотек меняются не очень часто, может быть, в случае локального исправления или какой-либо функции \ исправления, реализованной в более новой версии, я думаю, что это может принести пользу проекту. Внутренние библиотеки меняются довольно часто (циклы 1 месяц) и предоставляются другой командой в моей компании в двоичном виде, хотя у меня также есть доступ к исходному коду и, если мне нужно исправить ошибку, я могу сделать это и сгенерировать новые двоичные файлы для моего использования до следующего цикла выпуска. У меня сейчас есть следующие настройки (только для файловой системы):
-- dependencies
|
-- library_A_v1.0
|
--include
|
--lib
|
-- library_A_v1.2
|
--include
|
--lib
|
-- library_B
|
--include
|
--lib
| ...
Библиотеки хранятся на сервере, и каждый раз, когда я делаю обновление, мне приходится копировать любые новые двоичные файлы и заголовочные файлы на сервере. Синхронизация на стороне клиента выполняется с помощью утилиты синхронизации файлов. Конечно, о любых обновлениях библиотек нужно сообщать другим разработчикам, и каждый должен помнить, что нужно синхронизировать их папку «зависимости».
Нет нужды говорить, что мне не очень нравится эта схема. Поэтому я думал о том, чтобы поставить свои библиотеки под контроль версий (GIT). Постройте их, упакуйте в tgz \ zip и нажмите на репо. У каждой библиотеки будет свой собственный репозиторий git, чтобы я мог легко пометить \ разветвить уже использованные версии и протестировать новые версии. «Поток» данных для каждой библиотеки, который я мог легко получить, объединить, обновить. Я хотел бы иметь следующее:
избавиться от этой обычной файловой системы, хранящей библиотеки; в настоящее время для каждой ОС и каждой версии хранятся и управляются отдельные папки, а иногда они не синхронизируются, что приводит к путанице
больше контроля над ним, чтобы иметь возможность иметь четкую историю того, какие версии библиотек мы использовали для какой версии нашего проекта; очень похоже на то, что мы можем получить из git (VCS) с нашим исходным кодом
быть в состоянии пометить \ разветвлять версии зависимостей, которые я использую (для каждой из них); У меня есть тег / ветка v2.0.0 для library_A, из которого я обычно беру его для своего проекта, но я хотел бы протестировать диск версии 2.1.0, поэтому я просто собираю его, помещаю на сервер в другой ветке и вызываю мой скрипт сборки с этой конкретной зависимостью, указывающей на новую ветку
имеют более простые сценарии сборки - просто извлеките исходные коды с сервера, извлеките зависимости и соберите; это позволило бы также использовать разные версии одной и той же библиотеки для разных комбинаций процессор-ОС (это нам чаще всего нужно)
Я пытался найти некоторые альтернативы прямому git-решению, но без особого успеха - например, git-annex , который кажется слишком сложным для того, что я пытаюсь сделать.
С чем я сейчас сталкиваюсь, так это с тем, что существует очень сильное мнение против размещения бинарных файлов в git или любой VCS (хотя технически у меня были бы и заголовочные файлы; я мог бы также выдвинуть структуру папок, которую я описал непосредственно git, чтобы не иметь tgz \ zip, но у меня все еще были бы двоичные файлы библиотек) и что некоторые из моих коллег, движимые этим общим убеждением, против этой схемы вещей. Я прекрасно понимаю, , что git отслеживает контент, а не файлы , но в некоторой степени я буду отслеживать и контент, и я верю, что это определенно улучшит текущую схему вещей, которые мы имеем сейчас.
Что было бы лучшим решением в этой ситуации? Знаете ли вы какие-либо альтернативы схеме вещей, основанной на git (VCS)? Было бы чудовищно иметь мою схему под мерзавцем :)? Пожалуйста, поделитесь своим мнением и, в особенности, своим опытом в таких ситуациях.
Спасибо