Переход с ClearCase на SVN / Mercurial

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

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

Главное, что я усвоил, - это то, что процесс важнее продукта.

Если вы реализовали 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 делает исправление автоматически доступным для группы разработчиков, выпускающих SP2. Нет работы. Нада, ноль.

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

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

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

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

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

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

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

Я определенно рассмотрю переход от прозрачного корпуса к подрывной деятельности как обновление!

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

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

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

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

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

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

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

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

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

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

Что мне понравилось в ClearCase, что я не смог сделать так же хорошо или вообще в других инструментах SCM:

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

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

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

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

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

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

В Mercurial рабочий процесс проще. В нашем текущем проекте одна ошибка закончилась фиксацией файлов, не являющихся исходными. История Hg неизменна. У нас нет администратора. Один разработчик скопировал новый проект за полдня. В 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».

Я только что провел последние несколько недель на своей новой работе, изучая инструменты SCM (Управление конфигурацией программного обеспечения) и ALM (Управление жизненным циклом приложений), которые можно использовать для замены CVS и поддержки внедрения Agile.

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

Для простого решения SCM посмотрите следующее:

• Accurev: это инструмент SCM с встроенной поддержкой потоковой / параллельной разработки. Он предоставляет очень хороший браузер потоков, дающий вам графическое представление ваших потоков и позволяющий графически продвигать изменения как проблемы или как набор изменений (обеспечивает атомарное продвижение набора исходных файлов). Он имеет встроенное средство отслеживания проблем, которое дает вам возможность управлять изменениями и позволяет вам работать в соответствии с задачами. С AccuFlow вы можете еще больше контролировать свои изменения в рабочем процессе, а Accubridge обеспечивает интеграцию с IDE.
• Seapine Surround: это красивый инструмент, который хорошо работает для ветвления, но не настолько продвинут, как Accurev. Что приятно в Seapine, так это интеграция с их инструментом отслеживания проблем, TestTrack Pro, а также с их решением для управления тестовыми случаями TestTrack TCM (которые объединяются в TestTrack Stuido). Наконец, у них также есть QA Wizard Pro, который представляет собой веб-инструмент для автоматического тестирования winforms.
• PureCM: это еще одна альтернатива, которая довольно популярна, но я не рассматривал ее подробно.
• Perforce: еще одна альтернатива в этой области, которая меня не особо впечатлила, но у нее есть некоторые интересные нишевые функции, такие как возможность сравнивать и объединять изображения.
• Пластиковый SCM. Незрелый продукт, но очень интересный.

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

Если у вас обширное развертывание Rational, вы можете изучить следующие альтернативы:

• MKS Integrity: хороший, хорошо скомпонованный продукт, в котором есть отличные инструменты управления портфелем и удобное встроенное представление тестового запуска. Все его инструменты входят в одну среду IDE и легко настраиваются.
• Серена СМ: Опять же, достаточно хороший пакет с обширным набором инструментов для основного решения ALM. Очень большая часть управления портфелем, и есть много поддержки процесса покупки с их компонентами Mashups, а также поддержка прототипирования.
• Telelogic: По иронии судьбы, теперь он является частью IBM и вскоре станет IBM рациональным. Его решение SCM (Telelogic Change и Synergy) - лучшее, что я когда-либо видел, с возможностью явно продвигать изменения кода по задачам в ветку сборки выпуска.

Все вышеперечисленные решения поддерживают те же концепции SCM, что и Accurev и т. Д., Но, очевидно, представляют собой более сквозные продукты и имеют масштаб предприятия.

На данный момент мы сузили наш выбор до MKS или Telelogic.

Самым важным моментом для меня является то, что существует множество решений между ClearCase и CVS / Subversion, которые являются коммерческими, но относительно дешевыми.

Надеюсь, это было полезно.

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

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

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

Мне было бы интересно узнать, как устроена ваша структура веток.

Почему пользователи работают над «стволом» вашего продукта? (Я полагаю, это означает вашу основную ветку). Разве ветки разработки не мешают вашим разработчикам влиять на основной ствол?

Почему вы не могли ввести триггер в скрипте rmview, который не позволял бы пользователям удалять представление, пока у вас есть проверки? Это довольно тривиальное упражнение, и в Интернете есть множество источников (и я уверен, что StackOverflow предоставит вам ответы, если вы спросите!).

Другое предложение: если у вас уже есть деньги, вложенные в продукты IBM (и вы готовы потратить деньги на коммерчески поддерживаемую среду SCM), вы можете взглянуть на Team Concert и Jazz.

Мне кажется, вы будете счастливы в git / mercurial и, вероятно, не в SVN. OTOH, весь мой опыт работы с прозрачным кейсом был утомительным и нелюбимым, поэтому я считаю, что любое действие по побегу действительно очень хорошо.

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