Перемещение от ClearCase до Подвижного: Ваши главные подсказки?
Мы скоро начнем заменять ClearCase Подвижным. Я слышу, что это - хорошая вещь. Модель изменения по сравнению с моделью версии. Волна будущего. Я готов верить этому. Однако, это отчасти пугает меня. Эй, это взяло Joel Spolsky некоторое время к grok различие и как получить максимальное преимущество из Подвижного, таким образом, я держу пари, что столкнусь с концептуальными прерываниями и ловушками.
У кого-либо есть кто-либо реальным "как к grok Подвижным" подсказкам? Что-либо определенные предложения, которые помогут мне устранить концептуальный разрыв. Какие-либо предупреждения о вещах не сделать? Я ценил бы слушание их. Я уже считал самые близкие вопросы на ТАК связанном с этой темой, а также Подвижным туром и многими другими блогами. Я главным образом интересуюсь любыми глюками, или мм-ohs я могу встретиться. Любая мудрость, которую можно передать, будет цениться.
3 ответа
Видео peepcode meet mercurial стоит потраченного часа и $9.
Что касается ошибок, я бы сказал, что самая большая причина, по которой я вижу, как люди терпят неудачу в Mercurial, это то, что они слишком зацикливаются на том, "как они делали раньше", вместо того, чтобы сосредоточиться на том, "почему они делали эти вещи".
Люди будут биться головой о распределенную природу mercurial, чтобы подделать блокировку файлов, но они делают это потому, что раньше объединение было трудным, а теперь нет.
Или люди будут пытаться заставить автоматически обновлять идентификаторы ревизий в своих файлах, потому что раньше можно было проверять разные точки ревизии для каждого файла. Теперь это не так, так что иметь его только в одном месте вполне нормально, и это место обычно hg id.
Или вот ещё важный момент - mercurial вносит неизгладимые изменения - после того, как вы закоммитили/отправили изменение, нет простого способа (и есть множество сложных/плохих способов) впоследствии изменить это изменение. Вы можете свести на нет его эффект, но вы не можете отозвать и уничтожить его. В первый раз, когда кто-то нажимает на изменение, о котором потом жалеет, что не нажал, он проходит через такую последовательность:
- черт!
- Я хочу отменить это
- Я не могу отменить это?!
- Это самая глупая вещь, которую я когда-либо слышал!
и тогда они делают одно из двух: либо
- тратят время на то, чтобы понять, почему mercurial сделал неотменяемость хорошей вещью
либо
- идут на огромные ухищрения, чтобы удалить набор изменений из всех своих удаленных репозиториев и клянутся, что mercurial сломан
И последнее: принимайте взвешенное решение о том, какой из многих возможных способов ветвления вы выберете. Мне нравится первый вариант в этой статье, а ее автор предпочитает другой, но он дает отличный сравнительный контраст.
Вы, вероятно, читали это, но я только что прочитал и подумал, что это очень хорошее введение для нас (пришедших из SVN):
Сначала прочтите: « Какие основные концепции прозрачного корпуса должен знать каждый разработчик? ».
В этом ответе я сравниваю ClearCase с Git, но общая идея остается верной:
ClearCase (Central VCS) сильно отличается от Git или Mercurial (DVCS), и в этом ответе подробно описаны основные отличия .
Если вы можете поместить столько данных, сколько хотите в ClearCase VOB, любой путь миграции будет включать реорганизацию ваших данных в согласованное репо (т.е. репозитории с согласованными данными в них)
Проблемы при планировании для перехода с ClearCase аналогичны:
- Переход от clearcase к mercurial (который вы, возможно, уже читали)
- Переход от ClearCase , который напоминает вам, что вам необходимо установить политики для ветвления и маркировка сильно отличается от тех, которые выполняются с помощью ClearCase (особенно ClearCase UCM), поскольку публикация (push / pull) - это еще одно измерение, неизвестное в CVCS, таком как ClearCase.