Способ интеграции различных систем контроля версий или выбора одной из других в результате слияний и поглощений?

11

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

Есть ли общий смысл в том, как интегрировать такие системы вместе, например, с помощью моста Subverson-GIT или даже принять решение об использовании только одного инструмента поверх другого - и как выполнить миграцию между системами?

Используют ли люди набор критериев для принятия таких решений, например, эквивалент теста «Джоэл» по разработке программного обеспечения?

version-control migration therobyouknow
источник

Ответы:

11

Чтобы ответить на вопрос о миграции из личного опыта нескольких миграций:

Не бойтесь просто поместить текущую версию программного обеспечения в новую систему контроля версий в качестве базовой линии и работать оттуда.

В подавляющем большинстве случаев вам не понадобится история. Это означает, что во время интеграции нужно выполнить на одну задачу меньше, а с ошибкой - меньше.

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

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

ChrisF
источник
+1 справедливо, перенесите только то, что вам нужно, оставьте старые версии в прежнем хранилище. Не мигрируйте ради себя. Этот подход представляет собой вариант подхода к выбору между организацией и поиском. Если поиск может быстро получить то, что вы хотите, то нет необходимости организовывать то, что вы ищете.
therobyouknow
1
+1 ИМО лучшая стратегия. Продолжайте использовать только один, остальные в режиме только для чтения на всякий случай.
user281377
1
+1: более точный ответ по части миграции.
VonC
1
+1 - достаточно сложно понять существующий код, не говоря уже о последних трех версиях.
Джефф
1
Мы конвертировали многие CVS-репозитории в SVN с помощью классного скрипта cvs2svn, который работал очень хорошо. Я никогда не вспоминаю, как кто-то смотрел историю за «недавними изменениями», так что на самом деле это не стоило места на диске. Если бы я сделал это снова, я бы просто пометил репозиторий CVS, зарегистрировался в SVN как новый и затем пометил репозиторий CVS только для чтения.
JBRWilkinson
4

С управленческой стороны это в основном вопрос:

  • поддержка : будет ли компания, выпускающая VCS, все еще там в случае проблем.
    К сожалению, это одна из главных причин, почему такие устаревшие продукты, как ClearCase, все еще рассматриваются (ClearCase с 2003 года ... продукт IBM )
  • стоимость лицензии : даже если есть бесплатные альтернативы, иногда «групповые лицензии» для VCS могут быть согласованы или фактически включены в гораздо более крупный контракт, включая серверы, сети, поддержку и т. д. Глобальная лицензия на этот вид продукта может закончиться стоимость намного ниже, чем публичная цена.

На стороне проекта, это также вопрос:

  • администрация : на каком сервере вы будете устанавливать VCS (или много VCS, если мы говорим о Git, SVN и других)? С какой политикой резервного копирования? Что такое DRP (план аварийного восстановления)?
  • местная поддержка : кто возьмет поддержку уровня 1? уровень 2?
  • Знание рынка : вы уверены, что найдете достаточно разработчиков и / или администраторов с нужным набором знаний, чтобы использовать эту VCS и все ее функции?

Бесплатное или бесплатное программное обеспечение, помните, что «бесплатное» программное обеспечение бесплатно, как в «свободе слова» (вы можете свободно выбирать и развертывать то, что вам нужно), а не как в «бесплатном пиве» (оно все равно будет стоить много денег на сервере. , резервное копирование, администрирование, поддержка, ...)

Приведенные выше критерии - это начало, чтобы определить, какую VCS оставить, а какую отказаться.
Но в последнем случае необходимо учитывать:

  • Стратегия миграции : вы можете экспортировать / импортировать историю проекта из одной VCS в другую?
  • Стратегия моста : имеет ли смысл иметь историю в двух разных VCS?
  • Устаревание проекта : если проект находится в состоянии обслуживания / завершения срока службы, может быть лучше на короткое время поддержать старую VCS.
VonC
источник
+1 хороший ответ, маркеры обозначают критерии, которые я ищу, и ваши объяснения с ними тоже помогают. Я дам другим шанс, прежде чем принять ответ. Спасибо.
therobyouknow
1

Вы действительно нуждаетесь в интеграции различных систем? В нашей команде каждый проект живет в своем собственном репозитории, поэтому их история независима. У нас нет проблем работать с некоторыми проектами в Subversion, а в других - с Mercurial, даже если между ними есть зависимости.

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

редактировать

Я думаю, что понял кое-что, что было неявным в вопросе и других ответах. Это факт, что VCS также используются для управления зависимостями. Я знаю, что довольно часто используются такие функции VCS, как svn:externalsинтеграция одного репозитория (зависимости) с другим.

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

barjak
источник
Нужно интегрировать разные системы? Да, если работа одной команды используется другой командой. Интеграция может быть жесткой или проигрышной в зависимости от уровня необходимости и имеющихся кадровых ресурсов. Нет, если проекты полностью независимы. Единственная оставшаяся проблема - поддержка более чем одной системы и то, воспринимается ли это как хорошая или плохая вещь. Хорошо, если мы примем, что мы живем в разнообразном компьютерном мире, или плохо, если мы думаем, что должны сосредоточиться и проявить решительность ради самих себя, выбрав один из инструментов, который может быть чрезмерно солипстичным!
therobyouknow
PS. +1 Повезло тебе, баржак, за то, что ты находишься в организации, которая терпит разнообразную вычислительную среду.
therobyouknow
0

Много хороших ответов. Еще одна вещь, о которой стоит подумать, - не дать членам команды сойти с ума, думая, что переключение ВК - такая большая проблема. Будет миграция, кривая обучения и т. Д., Но если у них слишком много проблем, они должны поставить под вопрос свой уровень способностей и / или сотрудничества.

JeffO
источник
+1 Реализм тут. Люди должны сохранять самообладание, быть смелыми и действовать. Риски должны быть четко определены. На моем рабочем месте я вижу и слышу, как другие люди говорят, что иногда мы недостаточно усердно работаем над уменьшением неопределенности / четким определением рисков / непредвиденных обстоятельств, прежде чем приступить к работе. Может показаться, что для итерации "исправь-неправильно" / исправлено достаточно времени, но не хватает времени, чтобы все сделать правильно с первого раза. Исправление проблем вознаграждается и рассматривается как текущее действие, даже если иногда оно было ненужным.
therobyouknow
1
Это зависит от рассматриваемых VCS и от того, насколько хорошо выполнена миграция. Переход от Git или даже CVS к любой блокирующей VCS будет крайне неприятным.
Дэвид Торнли