На пути к идеальному рабочему процессу с ClearCase и Git

Вступление

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

Обычный рабочий процесс с ClearCase состоит из master филиал, а develop ветка и несколько новых функций ветвей.

        o--------o (feature)
       /          \
  ----o--o---o-----o----o (develop)
 /        \         \
*----------o---------o (main)

пример

На самом деле то, что я называю функцией, также может быть простым рефакторингом, таким как массовое переименование внутри проекта. В этом примере, так как ClearCase ориентирован на файл, нам всегда нужна временная ветвь (без атомарной регистрации в CC без UCM). Создание новой ветки является болезненным, а наличие правильной конфигурации - трудная задача. Отсюда я вижу два решения:

  1. Будьте корпоративны и начните массовую проверку всех файлов. Поскольку среда SCM не находится на том же сайте, что и серверы ClearCase, все становится медленнее. Я считаю 2s на файл и 8 минут для 1k файлов. После первого перерыва на кофе мы выполняем работу и проверяем все файлы (еще 8 минут потрачены впустую). Некоторые тесты, новая массовая проверка, исправление, массовая проверка, слияние с develop ветвь и в конечном итоге мы удаляем feature ветка, которая больше не нужна.

    В этом решении все идет медленно, много кофеина потребляется, а рабочий процесс довольно неэффективен. Я не думаю, что это хорошее решение.

  2. Поскольку мы хотели бы отслеживать наши изменения и не хотим тратить время на проверку / извлечение всех файлов проекта, мы запускаем Git-репозиторий из представления моментальных снимков. На самом деле, Git-репозиторий может быть расположен где-то еще, кроме ClearCase. Изменения вносятся локально с помощью Git, и, как только все будет сделано, проект отодвигается на ClearCase с clearfsimport, После этого нам еще нужно объединить feature ветка. Это сделано в УК. Затем ветвь объекта может быть удалена.

    Это решение требует много манипуляций. Также, clearfsimport может быть очень опасным, если мы неправильно напишем целевой вид или если забудем удалить все временные файлы. Последнее, но не менее важное, окончательное слияние должно быть сделано на CC.

Снимки просмотров

В моих примерах я не упоминал Snapshot Views, потому что они не совместимы с Git. Захваченный файл идентифицируется на основании его временной метки. Если я вручную изменю файл и восстановлю его первоначальную дату изменения, ClearCase не увидит никаких изменений. Это может быть очень опасно, как показано в следующем примере.

Если вы не верите мне, вы можете попробовать это:

stat -c 'touch --no-create -d "%y" "%n"' foo > restore_timestamp
echo "ClearCase will not see this" >> foo
source restore_timestamp
rm restore_timestamp

Благодаря этому механизму репозиторий Git не может находиться внутри ClearCase Snapshot View.

Отдельный репозиторий Git

Я сомневаюсь, что мы сможем найти обходной путь к требованию создания временного филиала. Объединение должно быть сделано в ClearCase, даже если Git держит все позади.

Я пытался широко использовать Copy/Paste для синхронизации полностью разделенного репозитория Git с ClearCase. Прямо перед финальным слиянием я копирую / вставляю текущее состояние develop перейдите в новую ветку Git и выполните слияние как можно быстрее. В конце я использовал clearfsimport подтолкнуть изменения обратно к develop ветка.

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

Эквивалент ClearCase "git checkout -b feature"

В Git, когда я хочу создать новую ветку, я просто набираю:

 git checkout -b feature

Вот и все, и я могу сразу же поработать над своей новой функцией. На ClearCase все немного по-другому.

Во-первых, мне нужно разместить ярлык, где я хочу создать свою ветку. Из Windows с Cygwin я могу сделать это:

LABEL=my_temporary_label
VOB=vob_name
cleartool mklbtype -global -nc lbtype:${LABEL}@\\${VOB}
cleartool mklabel -replace ${LABEL} `cleartool find . -cview -print -nxn | awk '{printf "%s ", $0}'`
cleartool find . -cview -type l -exec 'cleartool ls %CLEARCASE_XPN%' | \
   perl -p -e 's/\\/\//g' | \
   perl -p -e 's/\r//g' | \
   perl -e 'while(<>) {s@([.]/)(.*/)(.*-->\s*)@$2@;print;}' | \
   xargs -n1 cleartool mklabel ${LABEL}

Однако мы должны быть осторожны, потому что символические ссылки не раскрываются.

Затем должна быть создана ветка:

mkbrtype –c "Temporary Branch" my_temporary_branch

Для работы над этой веткой необходимо создать представление:

cleartool mkview -tag my_temporary_view \\shared\path\to\viewStorage\my_temporary_view.vws

Конфигурационная спецификация должна быть отредактирована:

element * CHECKEDOUT
element  .../lost+found -none

element * .../develop_branch/LATEST

mkbranch develop_branch
   element * /main/A_LABEL_WHERE_THE_BRANCH_IS_BRANCHED_ON
   element * /main/LATEST

end mkbranch develop_branch

Теперь ветка создана. Мы можем работать над нашей функцией. Полегче, а?

В Git я обычно создаю 3-5 веток в день. Я не думаю, что могу сделать то же самое с ClearCase. Я ошибся?

обсуждение

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

Я ищу решение, которое не связано со сложными манипуляциями. И я все еще верю, что Git может быть хорошим союзником, но как ClearCase и Git могут работать вместе?

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

Я не исследовал этот подход, но думаю, что есть одно решение, в котором мы можем использовать ClearCase Snapshot View с Git. Временная метка каждого файла должна быть сохранена перед внесением любых изменений:

 find . -type f -exec stat -c 'touch--no-create -d "%y" "%n"' {} \; > restore

Оттуда мы можем работать с Git, и как только пришло время отправить изменения в ClearCase или просто извлечь изменения из ветви разработки, исходная временная метка может быть восстановлена ​​во всех файлах, кроме измененных, с момента последней синхронизации:

 source ./restore
 git diff --name-only SHA1 SHA2 | xargs touch

Вопрос

На Stackru людям нравятся точные вопросы, а не первичные вопросы, основанные на мнении. Таким образом, после этого довольно длинного вступления я могу задать свой вопрос:

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

Это может быть сделано?

Источник

2 ответа

Решение

Возможное решение от VonC

В ответе VonC он предлагает не использовать промежуточную ветку и управлять всем с помощью Git.

На примере я хотел бы показать его метод. Мы начнем с этой конфигурации на ClearCase:

  o------o----o (develop)
 /        \ 
*----------o (main)

Идея состоит в том, чтобы использовать Git для облегчения разработки новой функции, которая в конечном итоге будет объединена с develop ветка.

Сначала мы копируем проект ClearCase в локальную папку и запускаем Git-репозиторий (в случае, если Git-репозиторий еще не существует).

WORKSPACE=~/foo
cp `cleartool ls -r | grep '@@' | sed 's/@@.*$//'` $WORKSPACE
cd $WORKSPACE
git init
git add .
git commit -m "Initial commit"
git checkout -b feature

Мы потратили некоторое время на разработку этой функции в собственной локальной ветке Git:

                  x----x--x---x----x (feature on Git)
                 /
                x---------- (master on Git)
               /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

В конце дня пришло время синхронизировать возможные изменения с ClearCase:

git checkout master
git --ls-files | xargs rm
cd $CCVIEW
cleartool ls -r | grep '@@' | sed 's/@@.*$//' > $WORKSPACE/ccview
cd $WORKSPACE
cat ccview | xargs -n1 cp {} $WORKSPACE    
cat ccview | xargs git add 
git commit -m "Imported from CC"

Итак, теперь мы сделали несколько коммитов на feature филиал и master Ветка Git была синхронизирована с ClearCase.

                  x----x--x---x----x (feature on Git)
                 /
                x-----------o (master on Git)
               /           /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

Мы не должны забывать блокировать представление ClearCase в течение всего процесса слияния. Это необходимо, чтобы другие разработчики не видели, как их собственные изменения стираются clearfsimport, Чтобы заблокировать ветку ClearCase, это просто:

cleartool lock brtype:$BR_NAME

Тогда слияние может быть сделано на Git:

git checkout master
git merge feature

feature Git ветка была объединена с master,

                  x----x--x---x----x (feature on Git)
                 /                  \
                x-----------o--------o (master on Git)
               /           /
  o------o----o------o----o (develop)
 /        \ 
*----------o (main)

Модификации могут быть перенесены обратно в ClearCase

OUT="$(mktemp -d)"
cp -v --parents `git ls-files | sed 's/[^ ]*\.gitignore//g'` $OUT
clearfsimport -comment 'clearfsimport' -rec -unco -nset $OUT $CVIEW    
rm -rf $OUT

И блокировку можно снять, чтобы заново авторизовать изменения в ветке

cleartool unlock brtype:$BR_NAME

,

                  x----x--x---x----x (feature on Git)
                 /                  \
                x-----------o--------o (master on Git)
               /           /          \
  o------o----o------o----o------------o (develop)
 /        \ 
*----------o (main)

Репозиторий Git и локальное рабочее пространство могут быть удалены, если только нам не нужно продолжать.

  o------o----o------o----o------------o (develop)
 /        \ 
*----------o (main)

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

VonC, не стесняйтесь изменить мой ответ, если я ошибаюсь.

Источник

На самом деле то, что я называю функцией, также может быть простым рефакторингом, таким как массовое переименование внутри проекта. В этом примере, так как ClearCase ориентирован на файл, нам всегда нужна временная ветвь (без атомарной регистрации в CC без UCM).
Создание новой ветки является болезненным, а наличие правильной конфигурации - трудная задача.

Итак... не создавать временную ветку?
Если это будет использоваться в сотрудничестве с Git, создайте только эту функциональную ветвь в репозитории Git, выполните окончательное слияние в Git Repo, а затем очистите команду importfsimport в главном представлении ClearCase.

Источник
Другие вопросы по тегам