Миграция с ClearCase на SVN / Mercurial

Question

На работе мы используем ClearCase прямо сейчас. Тем не менее, требуется много накладных расходов, особенно когда кто-то делает что-то глупое (например, стирает представление с несколькими зарезервированными извлечениями на стволе ...). Так как мы пытаемся снизить наши накладные расходы и быть максимально легкими, мы рассмотрели возможность отказа от CC и перехода на что-то более легкое (Subversion или Mercurial), понимая, как мы не используем 90% функций CC тем не мение. Это звучит разумно, или мы обменяем наш Ferrari на универсал?

Answer 1

По моему опыту, у ClearCase действительно много накладных расходов, и мы отлично справились с SVN.

Я голосую "понижение" (на самом деле это ОБНОВЛЕНИЕ). ;)

Answer 2

Главное, что я узнал, это то, что более важным, чем продукт, является процесс .

Если вы внедрили ClearCase (CC) с использованием модели типа SVN, то SVN будет работать просто отлично и будет стоить лот .

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

Я считаю, что большинство людей используют первый выбор, который похож на Ferrari в час пик ...

Пример? Определите метки GA, SP1, SP2 (вы можете иметь столько релизов между GA и SP1, сколько захотите, не важно, и помните, что метки CC НЕ совпадают с SVN). GA был твоим базовым релизом, SP1 - ваша текущая версия. SP2 - ваш следующий выпуск. Текущий выпуск основан на GA и SP1. Следующий выпуск основан на GA, SP1 и SP2 (см. Спецификации конфигурации CC)

Начните QA. Разработка выполняет постоянную работу для «следующего выпуска», и пользователи могут ссылаться (но не изменять) на GA и SP1, а также могут применять SP2. Техническое обслуживание выполняет работу по устранению дефектов, обнаруженных QA, может ссылаться на GA и применять SP1.

Случай 1: В ClearCase простое действие с применением метки SP1 делает исправление автоматически доступным для команды разработчиков Dev SP2. Нет работы. Нада, ноль.

В Subversion вы будете вносить изменения в ветку QA, а затем (надеюсь, не забудьте) перенести изменение в SP2.

Случай 2: Прежде чем вы спросите, конечно, если вы добавите изменение SP2, вам нужно будет перейти, чтобы добавить последующее изменение для SP1, как это было бы в большинстве систем.

В моем мире реальные цифры: Случай 1 случился 122 раза для моего последнего SP (8 SP в год). Более 800 изменений в год, которые мне не нужно было вносить в ClearCase, пришлось бы делать, если бы я использовал модель Subversion.

Случай 2 произошел 6 раз с начала 2002 года, когда мы установили CC.

Посмотрите на процесс , а не только на product .

(Извините за длину, это не началось так долго: -)

Answer 3

Я согласен с предыдущими постерами. Отказ от продукта IBM и переход на продукт с открытым исходным кодом для управления вовсе не будет понижением. Вы, вероятно, будете счастливее с этими более легкими и простыми в использовании инструментами. В нашем магазине мы находимся в процессе перехода от CVS к SVN и были очень довольны результатом.

Answer 4

Я бы определенно подумал, что переход с чистого листа на subversion - это обновление!

Answer 5

Мы перешли с ClearCase LT на SVN и нам это нравится. Мы экономим много денег на обслуживании, и все работает так же, как и раньше.

Хотелось бы, чтобы я исследовал Git или что-то в этом роде, прежде чем рекомендовать SVN.

Answer 6

У меня нет проблем с вашим "выключателем". Это будет обновление, если у вас не много взаимозависимых проектов, использующих UCM.

Я управляю SCM (ClearCase и Subversion) и рекомендую Subversion для малых и средних независимых проектов.

Однако убедитесь, что ваши разработчики не привыкли к динамическим представлениям ClearCase: это инкапсуляция файловой системы, позволяющая пользователю получать доступ к файлам из сети. Насколько мне известно, ClearCase является единственным, кто имеет такой доступ.

И принять во внимание сдвиг парадигмы:

• ClearCase ориентирован на файл (каждый полученный файл доступен только для чтения, и вы извлекаете только те файлы, над которыми работаете)
• Subversion ориентирован на репозиторий (каждый файл, который вы получаете, предназначен для чтения-записи, вы проверяете все измененные / добавленные / удаленные файлы за один атомарный коммит)

Answer 7

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

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

Из двух упомянутых вами, SVN - это тот, который вы должны выбрать, если в настоящее время вы используете централизованный репозиторий VC. Мало того, что операционная модель SVN проста и интуитивно понятна, у SVN просто лучшая документация и сообщество разработчиков, которое я когда-либо видел в проекте с открытым исходным кодом. Список рассылки для пользователей великолепен, разработчики отзывчивы и ответственны перед своими пользователями, а книга Red Bean - единственная лучшая часть руководства с открытым исходным кодом, пишущего там.

Answer 8

В моей предыдущей компании (процесс CMMi) около 100 разработчиков / тестировщиков / интеграторов работают с ClearCase (CC) с 3 администраторами, работающими полный рабочий день (добавьте 2 добровольных частично занятых). Если вы не используете часть управления конфигурацией (базовый уровень), вам следует перейти на современный SCM. Базовая функция является мощной: в традиционном SCM, когда вы обновляете / перебазируете, вы получаете последние версии по умолчанию. Базовая линия - это набор программных компонентов с определенной «совместимой» версией, чтобы убедиться, что сборка в порядке. В некотором смысле это похоже на построение зависимостей (например, Maven, Ant Ivy). Когда разработчики перезагружают (обновляют) базовый уровень, они получают то, что должно быть «компилируемым».

Теперь, оглядываясь назад на мою новую компанию (Agile shop), мы используем SVN и Mercurial, и я думаю, что CC была ежедневной болью. С CC для работы над проектом (хранилищем) у вас есть создание представления, создание действия, а затем извлечение файла. Некоторые коллеги боялись делать ветки :). С SVN и Mercurial у нас нет таких проблем с их клиентами GUI. Разработчики совершают 10 раз в день. В отличие от CC люди проверяли бы один раз в день.

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

В Mercurial рабочий процесс легче. Для нашего текущего проекта, один запутался из-за фиксации не исходных файлов. История ртути неизменна. У нас нет администратора. Один разработчик повторно клонировал новый проект через полдня. В Clearcase вам нужно будет попросить эксперта просто сделать резервную копию удаленного файла :). Чтобы создать новый репо, вы спрашиваете у администратора:)

После ухода из ClearCase теперь я действительно доволен SVN и особенно Mercurial. Таким образом, переход с ClearCase на Mercurial будет очень легким с точки зрения процесса, и вы получите большую производительность.

Теперь выбор между SVN и Mercurial? Вы должны спросить себя, является ли централизованное или децентрализованное хранилище. Вы можете выполнить быстрый поиск по stackoverflow.

Мне не понравились продукты IBM Rational в пользу элегантных решений с открытым исходным кодом.

Если вы прочитали это и поняли это, вам следует озаглавить «Обновление с clearcase до svn-mercurial» .

Добавлено: Clearcase находится за порогом рекомендуемости, тогда как Mercurial, Subversion & Git явно рекомендуются. http://martinfowler.com/bliki/VersionControlTools.html
Вы также можете комбинировать Mercurial & Clearcase. Прочтите параграф «Несколько VCS»

Answer 9

Вещи, которые мне нравились в ClearCase, которые я не смог сделать или вообще не использовал в других инструментах SCM:

1. Работа с ветками разработчика была безболезненной. В CC (UCM) вы работаете в своем потоке (a.k.a. branch) и «доставляете» кучу работы в поток интеграции. Между тем, другие разработчики делают то же самое. Затем интегратор (возможно, один из разработчиков) проводит некоторое тестирование в потоке интеграции, проверяет, что все строится и, возможно, тестирует дым, а затем рекомендует новый базовый уровень, который включает работу всех разработчиков. Тем временем вы продолжаете работать в своей ветке. В следующий раз, когда вы захотите доставить (или раньше, если хотите), вы увидите, что доступна новая базовая линия, поэтому вы объединяетесь с вашим потоком. Фактически, вы вынуждены сделать ребаз, если доступна более новая базовая линия. Я пытался сделать это в Microsoft Team Foundation Server и SVN. Во-первых, я не смог найти способ применения политики, такой как принудительная перезагрузка CC, поэтому мне пришлось пойти и выяснить, какие из моих ревизий я сделал со времени последнего слияния, и что было сделано в стволе с тех пор, и затем слиться из ствола в мою ветку. Затем, когда мне захотелось слить мою новую работу в ствол, мне пришлось заново слить все вещи, которые я только что слил, в свою ветку плюс мою новую работу.
2. Ветки разработчиков способствовали эффективному анализу кода. Когда я использовал CC, мы все пересмотрели. Практически, однако, обзоры занимали время, и нам нужно было продолжать работать. Каждый кусок работы соответствовал деятельности в ЦК. Только после того, как обзор был завершен, мы доставили действие в поток интеграции. Если для проверки потребовались изменения, я мог бы принять решение о внесении изменений в действие, которое я выполнял в исходной работе (при условии, что в файлы, измененные в этом действии, не было внесено никаких последующих изменений), создать новое действие для устранения изменений в обзоре, или возможно сдуть всю деятельность и начать все сначала (опять же, если не было внесено никаких последующих изменений). В TFS и SVN, когда вы что-то делаете, вы не можете легко вернуться назад, не отбросив последующую работу. Поэтому нам пришлось искать какой-то другой способ показать наши изменения другим разработчикам. Это привело к тому, что diff-файлы конвертировались в веб-страницы, но мы не могли продолжать работу, если бы она не смешивалась с работой, ожидающей рассмотрения.
3. Кроссплатформенная разработка упрощается благодаря динамическим представлениям. У меня есть только SVN, чтобы сравнить здесь, так что, возможно, Mercurial или другие лучше. Моя цель состояла в том, чтобы вносить изменения, собирать, тестировать, отлаживать на платформах Linux и PowerPC (и Windows для другого проекта) и зафиксировать один набор изменений, как только я буду рад, что он работает на всех платформах. Для сборок PowerPC у нас была солнечная рабочая станция (доступ к динамическому представлению), которую мы использовали для построения и тестирования цели. Это было медленно, поэтому мы выполнили большую часть нашего кодирования и отладки в Linux, а затем собрали и протестировали PowerPC перед окончательным тестированием на цели (PowerPC) и, наконец, проверкой. Одним из способов решения этой проблемы является использование сетевых файловых ресурсов. Одна проблема, которую я видел здесь, - несовместимость версий между Linux SVN и TortoiseSVN в Windows. Если вы пропустите Tortoise в репозиторий Linux, он изменит файлы .svn, а Linux svn пожалуется, что версия слишком новая. (Мы не смогли обновить наши Linux-боксы до достаточно нового svn из-за платформы, которую мы выбрали для цели.) Поэтому я не могу использовать мой инструмент сравнения Windows в репозитории Linux svn. Если я пойду другим путем, используя извлечение Windows и монтирование репозитория Windows, символические ссылки не сохранятся (которые необходимы при сборке Linux).

Я не согласен, поддержание ClearCase - это кошмар, а будет стоить вам 1012 * денег. Но после настройки он может обеспечить очень хорошую среду разработки. Особенно, когда вы начинаете интеграцию с ClearQuest (отслеживание дефектов, которое мы также использовали для отслеживания проверок кода).

Как заявил другой респондент, ответ для вас в значительной степени зависит от потребностей вашего процесса.

Answer 10

Я рекомендую прочитать HG Init - руководство Джоэла Спольски о том, как перейти с SVN на Mercurial.

Как упоминалось в некоторых предыдущих ответах, SVN и ClearCase в основном работают в одной и той же парадигме, поэтому, когда вы читаете статью, вы можете в значительной степени заменить каждое вхождение слова «Subversion» на «ClearCase» и применить его к вашей ситуации .

Это рецензия, которая окончательно убедила me начать использовать Mercurial на работе.