Какова наилучшая стратегия при переходе с ClearCase на SVN?

Мы рассматриваем переход от ClearCase к Subversion. Проект существует некоторое время (7 лет), и есть три "основных" версии (веток), которые мы активно поддерживаем, а также некоторые случайные исправления в более старых версиях. Проект довольно большой - около 2 миллионов строк кода Java.

Мне любопытно, есть ли кто-то, кто сделал подобную миграцию.

  • Будет ли SVN работать с таким крупным проектом?
  • Имеет ли смысл переносить все исторические версии/ветки? Являются ли инструменты, которые могли бы сделать это выборочно?
  • Как долго будет проходить процесс миграции для такого проекта и каков эффективный способ работы, тогда выполняется миграция?

ОТВЕТЫ

Ответ 1

Чтобы сделать несколько миграций такого рода, я бы сказал, что:

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

  • вам нужно подумать о реорганизации во время миграции: что вы импортируете?, что вы уезжаете? и хотите ли вы, чтобы контент SVN отражал именно структуру файлов как хранится в ClearCase VOB? Иногда такие миграции являются поводом для переосмысления некоторых из этих файлов (обычно с помощью простых правил переименования для определенных каталогов).

  • миграция выполняется быстрее в SVN-режиме ClearCase 2, поскольку SVN ориентирован на репозиторий и передает набор файлов, в то время как ClearCase является файловой системой и фиксирует файлы за файлом (много sloooower)

  • если набор файлов для импорта четко идентифицирован, процесс миграции может повторяться несколько раз, что означает, что вы можете продолжать работать в ClearCase, когда происходит первый (большой) импорт, затем Базовый уровень (метка UCM) в вашем коде и повторно импортировать только дельта, что фактически завершает процесс миграции.

Ответ 2

Сначала несколько ресурсов:

Размер фактического репозитория, количество файлов или их размеры не являются ограничивающим фактором для SVN. Количество разработчиков, concurrency изменений, сложность процесса интеграции и выпуска, необходимость объединения и управления версиями каталогов (рефакторинг) могут создавать проблемы для большого проекта. Если ваш проект просто большой, но он довольно стабилен, с небольшим количеством разработчиков, небольшим количеством веток и отсутствием необходимости в резервном наборе исправлений в несколько предыдущих выпусков, SVN должен сделать для вас очень хорошо.

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

Я лично попытаюсь собрать как можно больше данных, но вы должны знать ограничения SVN по сравнению с ClearCase. Любая история управления версиями каталогов (рефакторинг), вероятно, будет потеряна во время этой миграции. SVN не поддерживает разреженные ветки, такие как ClearCase, которые могут раздувать размер вашего репозитория SVN, если вы использовали ветки задач. В этом случае вы, вероятно, хотите ограничить себя только ветвями системы. Файлы в ClearCase имеют отдельную ветвящуюся структуру, а SVN имеет вид веток для каждого продукта, что приведет к большому сдвигу ветвления в процессе. Ограничивая себя ветвями системы и, возможно, просто помеченной версией на этих ветках для полностью интегрированных меток в серии, вы можете сэкономить массу неприятностей. Если ваша команда использует UCM, вы можете в значительной степени забыть все метаданные UCM. Они не будут переведены в SVN.

Временной интервал во многом зависит от используемых инструментов. Для такого крупного проекта, как у вас, это может быть даже недели. База данных ClearCase по какой-то странной причине блокирует даже операции чтения, и есть одна центральная таблица всего, что создает множество проблем при крупномасштабном доступе, таком как миграция. В первый раз, когда я запускаю свой инструмент на продукт, который несколько больше вашего, мы предположили, что он будет работать в течение 3 лет, после значительной оптимизации, распараллеливания и постепенной миграции он сократится примерно до недели. Но ожидайте, что в зависимости от того, насколько хорошо инструмент будет сделан, в то время, когда это потребуется, может быть много различий. Хотя, поскольку вы переходите в SVN, и вы игнорируете много истории и метаданных ClearCase, ваша миграция должна быть намного быстрее.

ClearVision упоминает на своих страницах, что его инструмент CC2SVN может создать мост между двумя продуктами. Хотя я не использовал этот инструмент, если он работает, как я предполагаю, он позволит вам синхронизировать 2 репозитория после некоторой обработки, что позволит вам переключиться на выходные, с нулевым временем простоя разработки. Если это невозможно, попробуйте попросить альтернативную, например, инкрементную миграцию, где вы сначала перенести данные до некоторой даты, а затем перенести меньший фрагмент данных, измененных с этой даты.

Очень важной частью процесса является фаза пост-миграции. Пожалуйста, не уменьшайте головные боли, которые коммутатор принесет вашим разработчикам. Вы не должны недооценивать необходимость в обучении и четкой документации. Вам также понадобится подготовленная группа поддержки в вашем отделе разработки программного обеспечения, способная работать как с системами SCM, так и с объяснением разработчикам, как делать то, к чему они привыкли в новой системе. Это на самом деле точка, которая может сломать шею в процессе миграции. Разработчики сопротивляются любым изменениям и любым преимуществам, которые SVN приносит в проект, это по существу намного более низкая система. ClearCase дает вашим разработчикам столько гибкости, которых у них никогда не будет с SVN, и если вы не принесете их на борт на ранней стадии процесса, вы можете потерять их или, что еще хуже, вернуть всю миграцию, объявить катастрофу и потерять свою собственную работу.

Ответ 4

  • Да, Subversion может обрабатывать очень большие проекты. Например, все Apache projects находятся в одном репозитории Subversion с подпроектами, являющимися простыми подпапками
  • Если имеет смысл преобразовать всю историю, вы должны решить сами. Но есть много доступных инструментов. Хорошее сообщение в блоге можно найти здесь.
  • Я не знаю, сколько времени займет такое преобразование. Но вы можете попробовать сначала с небольшим подмножеством и измерить время.

Ответ 5

Другой вариант - Migrate2SVN. Разработчик (Clearvision) только что выпустил v2.0, и он, как представляется, включает в себя много МНОГИХ улучшений программного обеспечения Polarion и других методов, упомянутых выше.