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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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