Параллельно создавайте git history, blob и tree объекты
Наша компания решила перенести наш исходный код с clearcase на git, это здорово:-)
Я знаю, что clearcase и git - это совершенно разные системы управления исходным кодом. Но у нас, разработчика, будет только один SCM, содержащий полную историю.
Моя коллега нашла следующий инструмент, который импортирует нашу историю открытых копий в git: https://github.com/charleso/git-cc
К сожалению, наш код содержит более 46000 файлов исходного кода, а история импорта составляет более 10 лет.
Я проанализировал этот инструмент и, по моему мнению, есть два узких места. Первый - это импорт файлов с сервера clearcae. Это легко решить, выполнив это в нескольких потоках. Второй - это рабочий процесс самого git-cc.
- Получить историю мастер-ветки через cleartool lshistory
- Создать наборы изменений файлов и сгруппировать их для комитетов
- Получить указанную версию файла (ов) с cc сервера и скопировать в рабочий каталог
- мерзавец добавить.
- мерзавец совершить
- выберите следующую группу и снова начните с 3.
Я думаю, что я мог бы улучшить это, используя низкоуровневые команды git и используя несколько потоков.
Каждая comit-группа запрашивает свои изменения с сервера и создает объект blob в базе данных git, так что это может выполняться для нескольких групп в нескольких потоках. Дополнительно у меня есть один поток, который создает историю в git из только что созданных объектов BLOB.
Мой вопрос сейчас, имеет ли это смысл для вас или вы думаете, что я наивен?
Я забыл какой-нибудь механизм блокировки мерзавца?
У тебя есть другие идеи?
1 ответ
Использование нескольких потоков для импорта коммитов в одной и той же ветке репозитория Git рискованно (если, как вы выразились, вы не создадите "объект blob", то есть патчи, которые вы можете воспроизвести).
Но использование нескольких потоков для коммитов на разных ветках возможно: вы создаете разные репо, каждое для импорта веток, а затем вы можете получить эти репо в одно общее репо и прикрепить их с помощью git replace
или прививки.
Но помните: каждое Git-репо является компонентом, поэтому, если ваш гигантский ClearCase Vob включает в себя несколько компонентов (группу файлов), было бы лучше разделить их в нескольких Git-репо, чем пытаться создать гигантский Git-репозиторий.
Я подробно описал это в разделе "Перенос ClearCase для Git".