Перенос из ClearCase в SVN/Mercurial

Ответ 1

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

Я голосую, "понижаю" (на самом деле это UPGRADE).;)

Ответ 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.

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

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

Ответ 3

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

Ответ 4

Я бы определенно рассмотрел переход от четкости к подрывной модернизации!

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

И учитывать сдвиг парадигмы:

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

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

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

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

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

Если вы прочитали это и поняли его, вы должны назвать "Модернизация от четкости до svn-mercurial" .

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

Ответ 10

Я только что провел последние несколько недель на своей новой работе, изучая инструменты управления SCM (Software Configuration Management) и ALM (Application Lifecycle Management), чтобы принять их для замены 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 есть такие концепции suppert, как песочницы разработчика (вместо использования этих безумных представлений в ClearCase) и моментальные снимки. Ежемесячно ветвь readonly, немного похожая на базовую линию.

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

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

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

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

Ответ 13

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

Распределенные системы звучат так, как будто они соответствуют вашему рабочему процессу.