Определение границ в терминах хранилищ

Question

Сначала я установлю сцену ...

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

У нас есть веб-приложение, а также приложение для веб-автоматизации.

Они не зависят напрямую друг от друга с точки зрения кода. Но приложение автоматизации зависит от веб-приложения с точки зрения дизайна. Внесение изменений в веб-приложение может привести к поломке приложения автоматизации.

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

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

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

Answer 1

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

Если у вас есть инструмент, который работает таким образом, тогда не так важно ограничивать количество отслеживаемых номеров ревизий. Я разделил это так - 1 число можно отследить вручную,> 1 нужна поддержка инструмента. Но они не должны быть сложными инструментами.

Я предпочитаю один репозиторий, но это всего лишь личное предпочтение. Он основан на однозначности номера ревизии, для нескольких репо нужен репо и номер. Границы репо устанавливаются при изменении политики (например, этот используется для кода, этот - для документов компании, этот - для развертывания и т. Д.).

Git просто так не работает, поэтому у вас нет возможности использовать один репо. Это неплохо, и большинство систем (таких как Hudson, Redmine) с радостью поддержат это.

Answer 2

Разделение их позволяет им выпускать независимо, с их собственными номерами версий, но, как вы заметили, отслеживать зависимости может быть сложно. Мы перешли от сборки на основе Ant к maven, чтобы помочь нам с нашими зависимостями, и, несмотря на некоторые проблемы с прорезыванием зубов, в целом это того стоило. (У нас есть несколько приложений, которые странным и удивительным образом зависят от apis друг друга.) Основная схема, которой мы следуем, заключается в использовании версии Apache Portable Runtime с номером , которая представляет собой трехзначную систему, в которой версии используйте стандартное соглашение MAJOR.MINOR.PATCH.

Что касается процесса их разделения, я бы рекомендовал сначала разделить их в Subversion; затем, если / когда вы переходите на git, вы можете просто указать git svn на соответствующие части хранилища для конвертации.

Answer 3

сначала вы создаете клон вашего репозитория svn, затем можете разделить полученный репозиторий git с помощью git filter-branch.

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