Каковы лучшие практики для перемещения между системами контроля версий?

Question

Существует около 200 проектов в cvs и не менее 100 проектов в vss. Некоторые из них неактивны в режиме обслуживания. Некоторые из них являются устаревшими приложениями. Некоторые старые приложения больше не используются. Около 10% находятся в активной разработке. План состоит в том, чтобы переместить все, чтобы выполнить мой конец 2009 года.

Кто-нибудь делал такую ​​большую миграцию?

Кто-нибудь сталкивался с лучшими практиками перехода от cvs к выступлениям? Или аналогичная миграция. Есть ли какие-нибудь проблемы, на которые стоит обратить внимание?

Answer 1

На стороне VSS есть инструменты преобразования, которые могут помочь с миграцией. В основном они могут поддерживать историю версий (есть предостережения, которые описаны в файлах readme и docs). Я перенес более 50 проектов VSS в исполнение, используя инструмент VSS для исполнения. Получение данных из VSS может быть немного сложным и не очень быстрым, но это работает. Если у вас есть прямой доступ к дискам (т. Е. Не через общий сетевой ресурс) к хранилищу VSS, преобразование может пройти намного быстрее. Вы можете найти информацию о скриптах здесь .

Здесь есть страница с симларом для CVS для выполнения конвертации здесь , хотя у меня нет прямого опыта с этим. Эти ссылки хорошие места для начала. Вы также можете осуществлять поиск в списках рассылки Perforce в Базе знаний Perforce, расположенной здесь . Я почти уверен, что вы можете найти некоторую информацию о конверсиях в архивах списков рассылки.

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

Самая большая ошибка могла бы на самом деле подготовить ваших людей к использованию Perforce. Если бы я сделал это снова, я бы сначала перенес наши небольшие активные проекты и подготовил бы меньшее количество людей к использованию Perforce сразу. В первый день после миграции мне пришлось обучать более 120 человек, и это было немного. Кроме того, убедитесь, что в первый день у вас не будет более 100 человек, которые обращаются к вашему серверу для новой синхронизации. В первые несколько дней мы несколько раз отключали наш сервер. Мы использовали Windows 32-битный сервер, который я бы не рекомендовал. Теперь у нас есть 64-битный сервер Windows, и он намного надежнее. Если бы вы могли, я бы на самом деле использовал Linux в качестве вашей ОС для вашего сервера перформанса. Опять же, на сайте Perforce должна быть хорошая информация о производительности.

Answer 2

Мне не приходилось делать что-то такого масштаба, но у меня есть несколько идей. Прежде всего, начните с небольшого, неважного проекта и перенесите его. Это даст вам представление о том, сколько трудностей потребуется для переноса остальных проектов. Сразу после этого вам следует выбрать проект среднего размера, так как могут возникнуть проблемы с переносом более крупного проекта (например, с ветвями), которые могут быть неочевидны в небольшом проекте.

Удостоверьтесь, что вы потратили немного времени, чтобы увидеть, как легко конвертировать cvs проекты в vss или наоборот. Если преобразование из VSS в перформанс представляет собой настоящую боль, вы можете конвертировать VSS в CVS, а затем выполнить. Не погружайтесь в это дни, но это может вывести вас из неприятной ситуации. Я думаю, что ключ здесь идет постепенно.

Резервные копии хорошие. Период.

Рассмотрим дату окончания, и любые проекты, которые неактивны и старше, чем это, должны быть законсервированы. Проверьте окончательный вариант и сохраните его в Perforce. Вам действительно нужен 15-летний визуальный базовый код?

Answer 3

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

Answer 4

Мы перенесли наш svn-репозиторий с помощью инструмента, который мы написали, и просто взяли на себя основную ревизию наших проектов Starteam.

Обратите внимание на различия между проверками в одном файле (CVS) и изменениями в нескольких файлах (Perforce).

Остерегайтесь ветвей - это отдельное пространство (CVS) и ветви в файловом пути (Perforce).

Answer 5

Не переносите мертвые и неактивные проекты. Просто поместите их репозитории в режим только для чтения. Данные по-прежнему будут доступны при необходимости, и вы сэкономите время на их перенос. Просто перенесите 10%, которые используются. Документируйте процесс полностью.

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

Answer 6

Простите, что отвечаю на вопрос вопросом, но разве Perforce не предоставляет инструменты для этого? Или, по крайней мере, документация? Я бы побил моего продавца Perforce ...