Миграция Clearcase в X

Question

Меня попросили выбрать альтернативу Clearcase-UCM с открытым исходным кодом, и мне нужен совет, какой будет наилучшим совпадением. Ниже приведены некоторые параметры, которые я собрал:

• Половина команд разработчиков использует методологию представления Интеграция, ракурс разработки, ребазинг и доставку. Остальные просто работают прямо в своем потоке интеграции с частными представлениями, как если бы это был транк.
• все команды используют базовые показатели для маркировки версий.
• Они утверждают, что сталкиваются с проблемами слияния с Clearcase-UCM, поэтому альтернатива должна иметь хорошо спроектированные возможности слияния.
• Нулевое обслуживание - для инструмента нет администратора VCS.
• Разработка на основе Windows, поэтому инструмент должен иметь хорошую поддержку win32.
• Интеграция с IDE (затмение).
• Поддержка Mac-OS.
• приятно иметь: инструмент миграции.

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

Answer 1

Когда вы используете UCM и создаете базовую линию, вы фактически идентифицируете ревизию заранее определенной подгруппы хранилища (компонент UCM, определенный в Vob, если вы не определили один весь Vob в качестве компонента)

Поэтому, если вы используете SVN, Git или Mercurial, вы должны понимать, что каждый из ваших компонентов UCM фактически будет одним (SVN-Git-or-Mercurial) хранилищем.

Кроме того, вам нужно будет воссоздать понятие зависимостей UCM («редактировать базовые зависимости», которых нет ни у одного из этих инструментов).

Принцип ближайшего приближения описан в этом SO ответе : это может быть сделано, но остается ручным.

Примечание: «Нулевое обслуживание - для этого инструмента нет администратора VCS». ... с этим все в порядке:

• резервное копирование
• DRP (План аварийного восстановления)
• правильный доступ для определенных репозиториев с «чувствительным» контентом
• скриптинг и инкапсуляция клиента для определенных операций
• ....

Не имеет значения, какой инструмент вы выберете, вам понадобится администратор (не полный рабочий день, но все еще довольно вовлеченный в задачи администратора)

---

Относительно "отслеживаемости", которая в основном представлена ​​действиями в UCM, но также и иерархией потоков, позволяющей определить рабочий процесс слияния, в Git / Mercurial это не очень хорошо работает: эти инструменты разные.

Для Git коммит - это самое близкое действие, особенно если учесть, что * git rebase -i (интерактивная перебазировка) позволяет вам переопределить содержание коммита (немного похоже на повторный выбор действия для нового действия). выписка)
Что касается слияния, так как они так просты в Git или Mercurial, нет реального «рабочего процесса слияния», формально определяемого с помощью операции доставки / ребазирования.
Скорее частные ветки создаются и используются / объединяются по усмотрению пользователя, некоторые из этих веток публикуются в другом внешнем хранилище.

Answer 2

Я не могу говорить об инструменте миграции, но Mercurial отлично сработал для нас. У нас есть смесь пользователей WinXP, Mac OS X и Linux, и никаких проблем не было. Я не использую IDE, но я считаю, что Aptana приобрела группу pydev (Python для Eclipse), поэтому я не слишком удивлюсь, если у них это будет.

Answer 3

В некоторой степени с техническими частями легко разобраться - вы можете использовать его с MacOSX или нет, и т.д. Хитрые биты - это «услуги», которые вы покупаете как часть лицензии CC, и это не будет очевидным для разработчиков, и разработчикам не обязательно будет об этом беспокоиться.

Активы вашей компании будут находиться в репозиториях, которыми управляет выбранный вами инструмент, и переходить от одного инструмента к другому не всегда так просто. Итак, многое зависит от жизненного цикла ваших продуктов. Они на рынке 6 месяцев, 6 лет или даже дольше? Проблема с некоторыми из этих инструментов существует всего несколько лет, и они в какой-то степени подвержены моде. Git поддерживает, Bazaar, кажется, потерял самообладание.

Я бы посоветовал посмотреть, что Rational предоставляет в соответствии с вашим текущим соглашением, и попытаться найти инструмент, поддерживаемый поставщиком услуг, который предоставит вам эквивалентную услугу. Тогда сравните расходы.

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

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

Любой инструмент может не требовать обслуживания. Он ломается, вы его не исправляете и переходите на другой «инструмент месяца».