Как соединить git с ClearCase?

Question

Я недавно использовал git svn и очень понравилось. Сейчас я начинаю новый проект у другого клиента. На этом сайте SCM по выбору - ClearCase. Я не нашел запеченный эквивалент git svn для ClearCase. Есть ли кто-нибудь, кто пытался использовать git локально в качестве внешнего интерфейса для ClearCase, используя какие-то приемы, конфигурацию или сценарии с какой-либо степенью успеха? Если да, то можете ли вы объяснить используемый метод?

Answer 1

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

Мы использовали две директории, одну для снимка ClearCase и главного репозитория git, которую мы разделили среди всей команды и никогда не редактировали файлы, а другую для нашего "рабочего" каталога.

Подготовка в представлении снимка экрана ClearCase:

% git init
% git add ** / *. cxx ** / *. h ** / Makefile (и т. д.)
% git commit -m "initial"

Затем клонируйте в свой рабочий каталог:

% mkdir ~ / work
% git clone / path / to / repo

Работа в рабочем каталоге, на ветке:

% git checkout -b особенность
% ... редактировать / компилировать...
% git add -u
% git commit

Убедитесь, что снимок ClearCase соответствует первичной (что всегда было для нас, потому что мы поделились им с командой, и все мы использовали git).

Затем объедините ветвь с ведущим, перебазировав ее, чтобы избежать автоматической фиксации слияния:

% git checkout master
% git pull
Функция% git checkout
% git rebase master
% git checkout master
% git слияния
% git branch -d особенность

% git diff - имя-статус-источник / мастер

Подготовьте представление ClearCase, проверив / mkelem / rmname все измененные / новые / удаленные файлы, основываясь на выводе git diff --name-status, Для этого мы использовали скрученный вручную скрипт. Не забудьте проверить все каталоги, в которые добавлены / удалены файлы:

Затем отодвиньте git и вернитесь с помощью ClearCase:

% git push
% cd / path / to / repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

Кажется, что это много команд, но это включает в себя настройку, и ваш ежедневный рабочий процесс не использует много команд. Вы можете тривиально создать сценарий на шаге push-back-to-ClearCase и постепенно обнаруживать / показывать своей команде все классные дополнительные элементы git по мере того, как все привыкнут к основному рабочему процессу.

Настоящая прелесть этой системы в том, что через некоторое время, когда все будут хорошо знакомы с git, вы можете тривиально отказаться от ClearCase и всех связанных с ней индивидуальных работ и сборов обезьян. Может быть, дать парню компании ClearCase столь необходимый отпуск и некоторую переподготовку с экономией. (К сожалению, в моей компании все эти мерзавцы были скунс-рунами, и мы перешли на Subversion - вперед из ClearCase, но назад из git!)

Я настоятельно рекомендую вам использовать pristine скрипт из ClearCase Globally, Git Locally, который выполняется в представлении снимка экрана ClearCase и обеспечивает синхронизацию между ним и git. Мы настроили это как работу cron, которая запускалась два раза в день, а также запускали ее вручную, когда мы собирались вернуться к git. К сожалению, ссылка на сообщение в блоге больше не действительна. Однако скрипт все еще доступен на Github.

Answer 2

Хотя это может быть и без нескольких бородавок (вас предупредили), я чувствую, что должен упомянуть, что написал своего рода мост.

http://github.com/charleso/git-cc

Соединить две системы нелегко, и я бы хотел, чтобы мое решение было наполовину таким же хорошим, как git-svn. Большим ограничением является то, что вы действительно ограничены отражением одного потока; git-cc не может клонировать все ваши ветви Clearcase (как бы хорошо это ни было). Тем не менее, учитывая, что большинство альтернативных сценариев разрешается в одном представлении Clearcase, вы ничем не хуже (IMO).

Лично я нахожу историю очень важной, и чего не хватает другим решениям, так это их импорта истории в Git. Возможность время от времени запускать git-blame для файлов и видеть их настоящих авторов.

Если ничто иное, git-cc не может обработать вышеупомянутый шаг 'git log --name-status' в решении Мэтта выше.

Мне, конечно, любопытно услышать, что VonC и Мэтт (и другие) думают об этом, так как я согласен, что любой мост в Clearcase чреват трудностями и может быть больше проблем, чем стоит.

Answer 3

Один процесс, которым я обычно следую, это:

• Снимок компакт-диска в ClearCase view/vobs/myComponent
• git init.

Это позволяет мне рассматривать компонент ClearCase как репозиторий Git.
Затем я могу выполнить все необходимые ветвления и "частные" коммиты в этом репо, делая файл доступным для записи по мере необходимости (возможно в режиме моментального снимка).

Получив стабильный финальный коммит, я обновляю свое представление снимка, в котором перечислены все "похищенные" файлы: я извлекаю их и возвращаю обратно в ClearCase.

С учетом ограничений Git, репо для ClearCase (UCM) является правильным размером для репозитория Git.
См. Также Какие основные концепции должны быть понятны каждому разработчику? для сравнения между ClearCase и Git.

Идея остается:

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