Компании приобретают другие компании, которые используют разные системы контроля версий.
Есть ли общий смысл в том, как интегрировать такие системы вместе, например, с помощью моста Subverson-GIT или даже принять решение об использовании только одного инструмента поверх другого - и как выполнить миграцию между системами?
Используют ли люди набор критериев для принятия таких решений, например, эквивалент теста «Джоэл» по разработке программного обеспечения?
Ответы:
Чтобы ответить на вопрос о миграции из личного опыта нескольких миграций:
Не бойтесь просто поместить текущую версию программного обеспечения в новую систему контроля версий в качестве базовой линии и работать оттуда.
В подавляющем большинстве случаев вам не понадобится история. Это означает, что во время интеграции нужно выполнить на одну задачу меньше, а с ошибкой - меньше.
Файлы / проекты, которые активно разрабатываются, скоро создадут новую историю. Поэтому, когда вам нужно выяснить, почему было внесено изменение, есть вероятность, что история будет в текущем хранилище, поскольку это будет недавнее изменение.
Файлы / проекты, которые были стабильны до миграции, должны (при прочих равных условиях) оставаться стабильными после миграции, поэтому вам не нужно обращаться к истории. Мы обнаружили, что если бы нам пришлось исследовать ошибку в таком старом файле / проекте, имеющем историю, то это не принесло бы никакой пользы. Если вы сохраняете старый репозиторий доступным в течение 6 месяцев в году, у вас будет ссылка в таких случаях.
С управленческой стороны это в основном вопрос:
На стороне проекта, это также вопрос:
Бесплатное или бесплатное программное обеспечение, помните, что «бесплатное» программное обеспечение бесплатно, как в «свободе слова» (вы можете свободно выбирать и развертывать то, что вам нужно), а не как в «бесплатном пиве» (оно все равно будет стоить много денег на сервере. , резервное копирование, администрирование, поддержка, ...)
Приведенные выше критерии - это начало, чтобы определить, какую VCS оставить, а какую отказаться.
Но в последнем случае необходимо учитывать:
Вы действительно нуждаетесь в интеграции различных систем? В нашей команде каждый проект живет в своем собственном репозитории, поэтому их история независима. У нас нет проблем работать с некоторыми проектами в Subversion, а в других - с Mercurial, даже если между ними есть зависимости.
Если вы решите перейти с одного VCS на другой, посмотрите доступные инструменты преобразования. По моему опыту, у меня нет технической причины отбрасывать историю проектов.
Я думаю, что понял кое-что, что было неявным в вопросе и других ответах. Это факт, что VCS также используются для управления зависимостями. Я знаю, что довольно часто используются такие функции VCS, как svn:externalsинтеграция одного репозитория (зависимости) с другим.
Я думаю (техническая) причина, по которой наша команда не чувствует необходимости объединять (или объединять) наши две разные системы, заключается в том, что у нас есть отдельный инструмент для управления зависимостями. Наши репо не знают друг друга.
Много хороших ответов. Еще одна вещь, о которой стоит подумать, - не дать членам команды сойти с ума, думая, что переключение ВК - такая большая проблема. Будет миграция, кривая обучения и т. Д., Но если у них слишком много проблем, они должны поставить под вопрос свой уровень способностей и / или сотрудничества.