Ответ 1
По моему опыту, у ClearCase действительно много накладных расходов, и мы очень сильно справились с SVN.
Я голосую, "понижаю" (на самом деле это UPGRADE).;)
На работе мы используем ClearCase прямо сейчас. Однако требуется много накладных расходов, особенно если кто-то делает что-то глупое (например, стереть вид с несколькими зарезервированными проверками на багажнике...). Поскольку мы пытаемся снизить наши накладные расходы и быть как можно более легкими, у нас есть возможность опускать CC и идти на что-то более легкое (Subversion или Mercurial), видя, что мы не используем 90% функций CC так или иначе. Это звучит разумно или мы будем торговать нашим Ferrari за универсал?
По моему опыту, у ClearCase действительно много накладных расходов, и мы очень сильно справились с SVN.
Я голосую, "понижаю" (на самом деле это UPGRADE).;)
Главное, что я узнал, это то, что более важным, чем продукт, является процесс.
Если вы внедрили 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.
Посмотрите на процесс, а не на продукт.
(Извините за длину, это не началось так долго: -)
Я согласен с предыдущими плакатами. Отключение продукта 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, которое я не смог сделать или вообще в других инструментах SCM:
Я не согласен, поддерживая ClearCase - это кошмар, и он будет стоить вам денег. Но после его установки он может обеспечить очень хорошую среду разработки. Особенно, когда вы начинаете интегрироваться с ClearQuest (отслеживание дефектов, которое мы также использовали для отслеживания обзоров кода).
Как заявил другой ответчик, ответ для вас сильно зависит от ваших потребностей процесса.
В моей предыдущей компании (процесс 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"
Я только что провел последние несколько недель на своей новой работе, изучая инструменты управления SCM (Software Configuration Management) и ALM (Application Lifecycle Management), чтобы принять их для замены CVS и поддержки принятия Agile.
Если вы ищете что-то, что будет поддерживать истинный SCM с параллельным развитием и ветвлением, тогда, вероятно, есть больше альтернатив, чем вы понимаете.
Для простого решения SCM рассмотрите следующее:
Все эти решения предлагают гораздо лучшую поддержку ветвления, чем у ClearCase есть такие концепции suppert, как песочницы разработчика (вместо использования этих безумных представлений в ClearCase) и моментальные снимки. Ежемесячно ветвь readonly, немного похожая на базовую линию.
Если у вас обширное развертывание Rational, вы можете изучить эти альтернативы:
Все вышеперечисленные решения поддерживают те же концепции SCM, что и Accurev и т.д., но, очевидно, представляют собой более совершенные продукты и представляют собой масштабы предприятия.
Мы в этот момент сузили наш выбор до MKS или Telelogic.
Моя самая большая точка в этом заключается в том, что между ClearCase и CVS/Subversion существует множество решений, которые являются коммерческими, но крайне дешевыми.
Надеюсь, что это было полезно.
Я рекомендую читать HG Init - руководство Джоэла Спольски о том, как переключиться с SVN на Mercurial.
Как уже упоминалось ранее, SVN и ClearCase работают в рамках одной и той же парадигмы, поэтому, когда вы читаете статью, вы можете в значительной степени заменить каждое появление слова "Subversion" для "ClearCase" и применить его к вашей ситуации.
Это запись, которая, наконец, убедила меня начать использовать Mercurial на работе.
Мне было бы интересно узнать, как настроена структура вашего ветки.
Почему пользователи работают на "багажнике" вашего продукта? (Я предполагаю, что это означает вашу основную ветку). Разве ветки развития не позволят вашим разработчикам влиять на основной багажник?
Почему вы не могли ввести триггер на rmview script, чтобы пользователи не удалили представление, пока все еще есть проверки? Это довольно тривиальное упражнение, и есть много источников в Интернете (и я уверен, что StackOverflow предоставит вам ответы, если вы спросите!).
Другое предложение было бы, если у вас есть наличные деньги, уже вложенные в продукты IBM (таким образом, желая тратить деньги на коммерчески поддерживаемую среду SCM), вам может понадобиться посмотреть Team Concert и Jazz.
Звучит так, как будто вы будете счастливы в git/mercurial и, вероятно, не в SVN. OTOH, весь мой опыт прозрачности был утомительным и нелюбимым, поэтому я считаю, что любое действие "побега" действительно будет очень хорошим.
Распределенные системы звучат так, как будто они соответствуют вашему рабочему процессу.