Управление сторонними источниками и двоичными файлами, используемыми кодом под управлением источника

Ответ 1

Ярким решением для моей проблемы является git-subtree, который недавно был объединен с mainline git. Это обеспечивает справедливый баланс между моими требованиями и ограничениями платформы. Теперь у меня есть несколько репозиториев для внешних (у каждого есть ветка поставщика, а также ветка локальных изменений), и каждый репозиторий проектов принимает части этих внешних элементов в подпапки. Для того, чтобы все было организовано, я поддерживаю папки "bin" и "lib", которые содержат софт-ссылки на соответствующие файлы/папки во внешней папке externals.

git -subtree позволяет объединить поддерево из внешнего репозитория в подпапку. Подпапка может быть объединена взад и вперед с внешним репозиторием.

Плюсы/Минусы:

• Малый репозиторий. Репозиторий не такой маленький, как я бы хотел, но он содержит только необходимые части из внешних репозиториев. Чтобы сэкономить место, я стараюсь, чтобы внешние деревья были маленькими. Я считаю, что это хорошая цена, когда я получаю простоту и надежность; так как загрузка и обновление проекта - это просто git pull, и все связанные с проектом данные содержатся в одном репозитории

• Синхронизация Project/Externals - поскольку проект и внешние версии версируются в одном репозитории, я могу проверить любую ветвь/тег, которую я хочу, и ожидать, что он будет работать.

• Простота - ежедневная работа прямолинейна. Обновление внешнего репозитория, создание нового или переход на другую версию внешнего может быть сложным и требует специального синтаксиса. Однако это слишком много. Лучше всего, что сначала можно добавить новый внешний проект в этот проект и только потом разделить его (используя git -subtree) в свой собственный репозиторий.

• Кросс-платформа - Ну, это git

• Binaries - я решил избежать сохранения двоичных файлов и вместо этого предоставить Makefile. Я пришел к такому решению, поскольку некоторые из моих внешних факторов зависят от других внешних факторов, из-за чего очень сложно построить двоичный файл, который не меняется очень часто. Для некоторых внешних я сохраняю двоичные файлы из-за очень длительного времени сборки.

Состав:

/root
   /External
      /External1 (git-subtree from [email protected]:External1 v1.0)
      /External2 (git-subtree from [email protected]:External2 v0.7)
   /lib
      /libExternal1.a -> ../External/External1/libExternal1.a
      /libExternal2.a -> ../External/External1/libExternal2.a
   /include
      /External1 -> ../External/External1/include
      /External2 -> ../External/External2/include

Ответ 2

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

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

Ответ 3

Для сторонних источников, я думаю, что подмодули - это именно то, что вы ищете. Если вы не хотите требовать всю историю восходящего потока в каждом клоне, включите репозиторий вверх по течению со своим собственным, содержащим ветку ручной работы с необходимой историей. Посмотрите git commit-tree, чтобы посмотреть, как это сделать, это легко. Идентификатор commit не будет соответствовать авторитетным восходящим потокам, но идентификатор дерева будет.

Для двоичных файлов приложение git, по-видимому, является наиболее рекомендуемым способом хранения контента, который не подходит с фокусом источника git. Я не использовал его сам, но дизайн выглядит готовым к использованию, он также поддерживает несколько независимых `репозиториев и выглядит так же удобно, как это может быть разумно.

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