Миграция от Clearcase - PullRequest
       56

Миграция от Clearcase

8 голосов
/ 06 августа 2009

Мы мигрируем из Clearcase в другую VCS (возможно, SVN или Mercurial). Для компаний, которые осуществили этот переход, какие факторы они сочли важными при выборе другого инструмента VCS, и какие методы, по их мнению, облегчили переход?

Ответы [ 7 ]

3 голосов
/ 08 августа 2009

SVN и Mercurial оба являются хорошими SCM.Многие проекты с открытым исходным кодом используют их.Если ваш выбор только сузился до этих двух, то вы и ваша команда должны учитывать следующее:

Рабочий процесс и рабочий процесс

Как вы хотите выполнять коммиты и ветвления?Распределенный или чисто централизованный?Это связано и с политикой компании.Пойдите с SVN, если вы хотите, чтобы все было централизовано.Но это не значит, что у вас не может быть центрального хранилища с Mercurial.Весьма полезно, если ваша команда выберет DVCS, например Mercurial, потому что:

  • У каждого есть своя локальная копия.Это позволяет им работать из дома и выполнять локальные коммиты
  • Каждый может выполнять локальное ветвление на своем локальном компьютере.Не бойтесь слияния между ревизиями, Mercurial имеет хорошую поддержку слияния и сравнительно прост по сравнению с SVN.
  • Не каждый должен иметь коммитный доступ, потому что вы можете назначить кого-то привратником, который получает ревизию с компьютера другого разработчика.Это позволяет выполнять проверку кода перед отправкой кода в центральный репозиторий.

Кроме того, оба они действительно хороши, поскольку имеют хорошую (достаточную) производительность, хорошую поддержку Windows ()SVN , Hg ) и хорошая документация / книга ( SVN , Hg ).

3 голосов
/ 07 августа 2009

Пара для добавления:

  • Производительность: медленные средства разработки прерывают мыслительные процессы разработчиков
  • Мощность (функциональность): насколько хорошо слияние? Новые инструменты, такие как git, гораздо лучше поддерживают и отслеживают слияние, чем инструменты старого стиля, такие как CVS и SVN Git также предлагает очень удобные инструменты, такие как bisect, которые ускоряют процесс разработки.
  • Поддержка сообщества: насколько широко принят инструмент? Вы не хотите выбирать то, что будет через пять лет в будущем.
2 голосов
/ 24 сентября 2009

В общем, я бы всегда использовал распределенную систему контроля версий (DVCS). Я не пробовал Mercurial, но мерзавец; но предпосылка здесь та же.

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

То, что вы не должны недооценивать, это сила местных отделений. Ветвление в централизованной системе довольно громоздко, ветки разработчика или функции создаются редко. Разработчики скорее имеют несколько рабочих копий или хранят небезопасные изменения в своей рабочей копии, чтобы не нарушать сборку. С децентрализованной системой разработчик создает местный филиал, работает над ним. Прерванный ошибкой show stoppper, он переключается обратно в ветку master, исправляет проблему, переносит изменения в центральный репозиторий и обратно в свою ветвь функций. Рабочий процесс чрезвычайно плавный.

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

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

В результате поведение разработчиков в отношении VCS определяется политикой компании, а не технологией, и вы можете изменить свою политику в любое время.

2 голосов
/ 06 августа 2009

Вам необходимо учесть несколько критериев, таких как:

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

В терминах миграция (в SVN или Mercurial) будет проще, если вы использовали ClearCase UCM, потому что базовые линии представляют четкую «временную шкалу» (ближайшую аналогию с « ревизия "), которую вы можете использовать для импорта в другую (D) VCS.
Если нет (Base ClearCase), вам необходимо учитывать, какую часть истории вам действительно нужно импортировать.

1 голос
/ 28 октября 2010

это старая ветка, но я хотел внести свой вклад. ИМО, SVN побежал своим курсом. Справедливости ради, если у вас около 50 пользователей или около того, и вы не делаете много ветвлений, то, конечно, это не будет хуже, чем CC. Однако, несмотря на то, что он старый и сложный, он все еще обладает развитой функциональностью. так что если вы зрелый магазин CC, SVN не удовлетворит ваши потребности. на самом деле, лучшая практика - меньше разветвляться и отрабатывать основной ствол. таким образом, лучший выбор (учитывая выбор выше) был бы Hg. Кроме того, я склонен к dvcs. истинные dvcs, то есть ... и есть только 2 варианта OSS: Hg и git. и в настоящее время одна коммерческая система, пластиковая scm. Если вы привыкли визуально представлять историю файлов (браузер vtree или браузер дерева компонентов в CC UCM, подумайте, так это называлось), пластик может быть более жизнеспособным выбором. как я уже видел, у него есть графическое дерево и что-то еще, например, ветвь дерева обозревателя. я помню, что поддерживал CC, где многие из нас по очереди переходили на доску и рисовали модель «процесса». пластик имеет встроенный. во всяком случае, опять я склонен к dvcs ... я достаточно страдал с svn и cc и пытался использовать дорогие инструменты репликации и сценарии мастерства. dvcs это так просто! если у вас жесткий носитель Linux / Unix, лучше выбрать git. если больше окон или смеси, Hg и Plastic выглядят как лучший выбор. больше графики и визуалов с пластиком. я думаю, что Хг пропускает много контроля доступа и контроля, к которому вы привыкли в CC ... так что у пластика здесь может быть преимущество. надеюсь, это поможет и удачи!

1 голос
/ 20 марта 2010

Если вы переходите от хорошего старого Clearcase ;-), взгляните на Plastic SCM. Большинство базовых понятий все еще будут присутствовать, но все болезненные моменты исчезли. И это распространяется. Проверьте следующую ссылку: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

1 голос
/ 06 сентября 2009

Поддержка третьих лиц. Есть ли в системе зрелый поставщик SCC для Visual Studio? (SVN да, Hg не взрослая).

Eclipse? Оба имеют хорошую поддержку.

Ваши разработчики привыкли быть коммандосом командной строки? Тогда сторонняя поддержка / плагины могут не быть проблемой.

...