Рабочий процесс с ртутными подкаталогами - PullRequest
3 голосов
/ 23 марта 2012

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

Предположим, мой репозиторий выглядит так:*

project/
  core/
  common/

Я не уверен, как должен выглядеть рабочий процесс.Когда я должен совершить project?Создавать ли на нем ветки объектов или только в подпапках?Что происходит, когда новая функция требует несовместимых с предыдущими версиями изменений как core, так и common?

Будем благодарны за любые дополнительные советы.

1 Ответ

1 голос
/ 29 августа 2014

Когда я должен совершить проект?

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

Создавать ли на нем ветви объектов или только в подпапках?

Вы должны создать репо «функции» как для репозитория проекта, так и для репо, в котором вы хотите реализовать эту функцию.

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

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

Затем для измененного под-репозитория будет просто создан запрос извлечения.

Что происходит, когда новая функция требует несовместимых с предыдущими версиями изменений как в ядре, так и в общем

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

В результате получается рабочая версия вашего проекта.

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

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

...