Преимущества / недостатки ClearCase

Поскольку я в настоящее время изо всех сил пытаюсь изучить IBM Rational ClearCase, я хотел бы услышать ваше профессиональное мнение.

Меня особенно интересуют преимущества / недостатки по сравнению с другими системами контроля версий, такими как Subversion или Git.

Источник

31 ответ

Решение

Вы можете найти хорошее сравнение между ClearCase и Git в моем ответе SO:
" Каковы основные концепции ClearCase, которые должен знать каждый разработчик? ", Иллюстрирующий некоторые основные различия (и некоторые недостатки ClearCase)

Файлово-ориентированные операции

Наиболее важным недостатком ClearCase является его старый " файлово-ориентированный " подход (в отличие от " репозиторий -ориентированного ", как в SVN или Git или Perforce...)
Это означает, что каждая проверка или регистрация осуществляется файл за файл. Атомарность операции находится на уровне файлов.
Объедините это с очень подробным протоколом и сетью с потенциально несколькими узлами между рабочей станцией разработчика и сервером VOB, и вы можете получить довольно медленный и неэффективный файловый сервер (который лежит в основе ClearCase).

Операции "файл за файлом" означают: медленные рекурсивные операции (такие как рекурсивная проверка или рекурсивное "добавление к управлению исходным кодом", даже clearfsimport).
Быстрая локальная сеть обязательна для устранения побочных эффектов этого болтливого протокола.

Централизованная VCS

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

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

Дорогая Распределенная опция VCS

Вы можете иметь некоторую распределенную особенность VCS, реплицируя Vob.
Но:

  • вам нужна специальная лицензия для доступа к ней.
  • эта лицензия стоит дорого и добавляет к стоимости обычной лицензии
  • Любой vob, который использует реплицированный vob (admin vob, admin pvob, ...), также должен быть реплицирован (то есть некоторые проекты, не связанные напрямую с распределенной разработкой, все равно должны будут платить лицензию на несколько сайтов...)

Старый и не удобный графический интерфейс

  • графический интерфейс очень старый и непрактичный (внешний вид MFC середины 90-х, полностью синхронный графический интерфейс, что означает, что вам нужно подождать обновления, прежде чем щелкнуть где-либо еще): при просмотре базовых показателей вы не можете быстро найти конкретный.
  • GUI в Unix не совсем такой же, как в Windows (последняя версия 7.1 лучше, но ее пока нет)
  • процесс установки довольно сложен (хотя последняя версия Installer Manager, представленная в CC7.1, теперь представляет собой целостный графический интерфейс для Windows или Unix и упрощает процедуру)
  • единственное по-настоящему многофункциональное приложение было разработано только для CCRC (удаленный клиент)

Несоответствия UCM и согласованность

Как упоминалось в разделе " Как использовать возможности ClearCase ", динамические представления - это великолепно (способ просматривать данные через сеть без необходимости копировать их на диск), но основной функцией остается UCM: это может быть реальным преимуществом, если у вас есть большой проект со сложным рабочим процессом.

Некоторые недостатки на этом фронте:

Ограниченные политики с Base ClearCase

Использование ClearCase без использования UCM означает необходимость определения политики для:

  • создайте ветку (в противном случае любой может создать любую ветку, и вы получите их из gazillon с кошмаром рабочего процесса слияния)
  • поставить метки (иначе вы забудете пометить некоторые файлы, или вы поставите метку там, где вы не должны были это делать, или вы "переместили" (задохнулись) метку из одной версии в другую: по крайней мере базовые показатели UCM не могут быть перемещены)
  • определить набор изменений. Наборы изменений существуют только с действиями UCM. С Base ClearCase вы превращаетесь в умного " cleartool find " Запросы...

Нет прав на приложение

Управление правами ClearCase полностью основано на правах системы.
Это означает, что вам нужно зарегистрировать своего пользователя в правильной системной группе, что не всегда легко сделать, когда вам нужно ввести билет в вашу ИТ-службу, чтобы он мог сделать правильную регистрацию.
Добавьте к этому гетерогенную среду (пользователи в Windows и сервер в Unix), и вам нужно зарегистрировать своего пользователя в Unix, а также в Windows! (с тем же логином / именем группы). Если вы не поместите какое-то соответствие LDAP между двумя мирами (например, Centrify)

Нет продвинутого API

  • только CLI завершен (" cleartool "Интерфейс командной строки ClearCase), означающий, что любой скрипт (на Perl или другом языке) состоит в разборе вывода этих cleartool команд)
  • ClearCase Automation Library (CAL) существует, но довольно ограничена
  • Java API существует, но только для веб-представлений для клиента CCRC.

Просмотр хранилищ не легко централизован

Хранилища представлений эквивалентны ".svn" SubVersion, за исключением того, что для каждого представления существует только одно "хранилище представлений" вместо множества.svn во всех каталогах рабочей области SubVersion. Это хорошо.

Плохо то, что каждая операция в представлении (простая ls ", checkout, check,...) вызовет сетевой запрос к процессу view_server, который управляет вашим сервером представления.
2 варианта:

  • объявите свое хранилище представлений на рабочей станции: отлично подходит для масштабируемости, вы можете иметь столько представлений, сколько хотите, не облагая налогом локальную сеть: все коммуникации осуществляются непосредственно на вашей рабочей станции. НО, если эта машина умирает от вас, вы теряете свои взгляды.
  • объявите свое хранилище представлений на централизованном сервере: это означает, что все процессы view_server будут созданы там, и что все операции над представлением любым пользователем должны будут взаимодействовать с этим сервером. Это можно сделать, если инфраструктура "правильная" (специальная высокоскоростная ЛВС, выделенный сервер, постоянный мониторинг), но на практике ваша ЛВС не будет поддерживать этот режим.

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

Побочное обсуждение динамических представлений:

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

Дело в том, что вы можете использовать оба по правильным причинам.

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

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

Разработка непосредственно в динамическом представлении не всегда является наилучшим вариантом, поскольку все (не проверенные) файлы считываются по сети.
Это означает, что dll, jar или exe, необходимые вашей IDE, будут доступны по сети, что может значительно замедлить процесс компиляции.
Возможные решения:

  • один снимок со всем в нем
  • представление снимка с dll или jar или exe в нем (файлы, которые не изменяются каждые пять минут: одно обновление в день) и динамическое представление только с видимыми источниками.
Источник

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

Тот факт, что это достаточно сложно, чтобы требовать няню на полную ставку, также вызывает беспокойство.

Источник

Абсолютный кошмар системы. Это заставило меня желать, чтобы мы могли вернуться к VSS! (Не берите в голову любую современную систему контроля версий, такую ​​как Subversion или Git!)

  • Это неопрятно.
  • Если вы используете динамические представления и сеть отключается, вы не можете получить доступ к своей рабочей копии источника. Вы можете ничего не делать, кроме как сидеть и ждать, пока все будет исправлено.
  • Если вы используете представления моментальных снимков, вы, кажется, все время сталкиваетесь с конфликтами и "угоняют" файлы, поэтому файлы в вашей рабочей копии никогда не бывают такими же, как в исходном репозитории.
  • Всякий раз, когда вы пытаетесь выполнить крупное обновление или выполнить доставку, оно неизменно по той или иной причине терпит неудачу, требуя, чтобы ваш гуру ClearCase потратил несколько часов / дней, чтобы выяснить это. О, да, у вас должен быть преданный, полный рабочий день гуру ClearCase!
  • Когда он терпит неудачу, вы часто не можете откатить операцию, так что вы застряли на незавершенной операции, и разработчики заблокированы.
  • Когда вы смотрите мимо симпатичных (?) Значков, графический интерфейс очень плохой - вплоть до невозможности изменить размер окна, чтобы увидеть полный путь к файлу!
  • Их вспомогательный персонал довольно неохотно что-либо исправляет. Их первый ответ всегда: " Это сделано специально " и "Вы можете обойти это?" Если они в конечном итоге предоставят исправление (после долгих споров), это будет самое основное возможное исправление самой неотложной проблемы.

По сути, это медленный, сложный и ненадежный ад. О, и я упоминал, что это смехотворно дорого? Единственный способ, которым они могут продать его, это поговорить с лицами, принимающими решения, которые никогда не использовали продукт и никогда не будут! Я совершенно уверен, что ни один разработчик в мире никогда не купит его.

Источник

Атомные коммиты и наборы изменений - мои самые большие проблемы с ClearCase. Допустим, вы отметили пять файлов как часть исправления ошибки или рефакторинга. Затем обнаруживается, что что-то испортилось, и вам нужно вернуться. Удачи в поиске пяти файлов и версии каждого из них. Но давайте сделаем шаг назад. Вы только что закончили редактирование этих пяти файлов, и пришло время зафиксировать. Первые четыре проходят просто отлично. Этот последний требует массивного слияния. Остальные четыре файла уже зарегистрированы. Они не ждут, пока вы внесете необходимые изменения в последний файл. Я уверен, что никто не обновляется или использует динамическое представление. Сервер непрерывной интеграции также может выйти из строя.

Иногда мы делаем полный новый каталог, содержащий файлы, которые необходимо зарегистрировать, но мы не хотим регистрировать их, пока они не будут завершены. Это рано и все еще нестабильно, так зачем отмечать вещи, которые вы можете удалить очень скоро? Хорошо, пока хорошо. Теперь пришло время зарегистрироваться. Вы добавляете вновь созданную папку в систему контроля версий. Что ж, ClearCase не является рекурсивным, поэтому проверяется только одна папка. С SVN эта папка и все, что находится под ней, добавляется по вашему выбору. Разработчик должен помнить, чтобы добавить все, в противном случае многие файлы будут отсутствовать.

ClearCase владеет файлами и папками, поэтому вы ничего не можете изменить, если вы сначала не проверили это. Плагин Eclipse устраняет много неприятностей здесь. Я не могу сказать вам, сколько раз я открывал файл в vi, чтобы сделать быстрое изменение, только чтобы обнаружить, что я забыл проверить его первым. Оформить заказ тоже не рекурсивно.

Обновления могут быть мучительно медленными без изменений. При обновлении с представлением снимка обновляются все файлы, а не только измененные файлы. Я работал над проектом с 20 000+ файлами. Я бы подключился к своей рабочей машине, запустил обновление и поехал на работу; получить кофе; иди к моему столу, пока он заканчивал. Это может звучать как преувеличение, но, к сожалению, это не так.

Динамические представления ужасны, если вы не в очень маленькой команде. И если это так, почему у вас даже есть ClearCase? Я видел бесчисленные взгляды людей, потому что кто-то проверял файлы, которые нарушали взгляды всех остальных. Вы должны всегда обновлять и объединять любые конфликты по своему собственному мнению. Таким образом, изменения влияют только на вас. При динамическом просмотре вы не можете объединиться, пока не вернетесь назад; Вы просто делаете и надеетесь.

Я знаю, что стоимость, вероятно, не является большой проблемой, но разработчики, которые зарабатывают деньги для компании, с удовольствием потратят $50–100 тыс. (В зависимости от лицензии ClearQuest, которая является обычным дополнением) на веселые мероприятия или новое оборудование (стулья, мониторы и т. д.). IBM рекомендует иметь персонал, чтобы поддерживать работу ClearCase. Почему бы не переориентировать этих людей на получение дохода для компании, вместо того, чтобы быть уверенным, что вещи не рухнут и не сгорят?

Некоторые из причин, которые я слышал, чтобы не переключаться:

  • Обучение займет время и деньги
    • Обучение SVN или Mercurial должно занимать не более суток. Только ClearCase предлагает иметь определенное соотношение администраторов и разработчиков.
  • Миграция будет болезненной
    • Вот почему существуют инструменты: cc2svn
    • С Mercurial это не так просто
  • Безопасность
    • В SVN AFAIK нет известных зияющих дыр, и команда разработчиков стремится быстро исправить все, что можно найти. Министерство обороны, кажется, в порядке с SVN.
  • Никакого реального увеличения производительности впоследствии
    • Требуется вечная попытка отследить ошибки без изменений. Мне нравится быть в состоянии откатиться, пока я не вижу ошибку. Вы не можете сделать это в ClearCase.
  • Многоузловое
    • WANdisco решает эту проблему. Это не бесплатно, хотя.

Единственное, что ClearCase делает лучше, чем остальные, - это разветвление отдельных файлов, в то время как остальные находятся на той же дорожке, что и другая ветвь.

Источник

Все, что я делал в Clearcase, всегда кажется сложным. Принимая во внимание, что у меня никогда не было такого впечатления с другими системами (за исключением, возможно, CVS).

Я использовал SVN, CVS, Clearcase и Mercurial.

Источник

Все, что я имел отношение к ClearCase в любом качестве, неэффективно, безобразно, слишком сложно, медленно, запутанно, дорого и неудобно.

Кажется, это привлекает менеджеров и инженеров, которые ТОЛЬКО ПОЛУЧИЛИ НЕПРАВИЛЬНО.

Черт, у IBM и Rational должны быть замечательные продавцы, чтобы продавать такой дерьмовый продукт.

Источник

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

Ваши важные бизнес-данные являются заложниками ClearCase. Вы не можете получить это.

Ваши жизненно важные бизнес-данные - это код, его история версий и все метаданные, такие как комментарии коммитов, кто зарегистрировался и когда.

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

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

Это будет где-то между неприятностью и проблемой для нас в краткосрочной и среднесрочной перспективе. Через пару лет это уже не важно, но, возможно, в течение 1-3 лет это будет иметь значение.

(Существуют коммерческие инструменты для миграции CC на другие SCM, но они не были сочтены адекватными нашим потребностям, и я сомневаюсь, что это было бы осуществимо. Минимальный экспорт, который мы сделали, занял достаточно много времени.)

Извлеченный урок: никогда не доверяйте важные бизнес-данные проприетарным системам.

Источник

Мой опыт работы с ClearCase был катастрофой, и я повторю заявление Дона о том, что для этого требуется эксперт-резидент - к сожалению, у нас их было больше одного. У меня был опыт работы с CVS и другими системами контроля версий, я был знаком с концепциями, но я обнаружил, что документация ClearCase непонятна, и мне пришлось несколько раз обращаться за помощью; разные эксперты давали мне противоречивые советы до такой степени, что мы фактически сломали CD. То есть после того, как я выполнил команду ClearCase в оболочке UNIX, команда "cd" завершилась ошибкой с сообщением об ошибке.

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

Источник

Нет атомарных коммитов

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

Crappy пользовательский интерфейс

Графический интерфейс ClearCase Explorer - просто большая шутка. Ужасный в юзабилити и безобразный вид. Различные и часто необходимые функции не предусмотрены (например, рекурсивная проверка работавших над артефактами). Инструмент командной строки cleartool, используемый с cygwin, намного лучше, но все же некоторые вещи недоступны, например, рекурсивное добавление новых файлов / папок в систему контроля версий. Я должен смеяться, если я читаю сценарий длиной в 50 строк кода, чтобы обойти это.

Высокие административные усилия

Администрирование ClearCase beast далеко не очевидно и не упрощено (в отличие от других scm-систем, таких как CVS, subversion или Git). Ожидайте, что довольно много преданных экспертов ClearCase просто сохранят его работоспособным.

Ужасное выступление

Нет ничего хуже, если заставить ваших разработчиков ждать при взаимодействии с SCM-инструментом, это все равно, что ехать с включенным ручным тормозом. Это замедляет ваш мозг, а также вашу работу. Получение новых файлов в виде снимка занимает около 30 минут для 10K артефактов. Обновление (никакие артефакты не были изменены) для того же количества занимает примерно 5 минут. Когда много экспериментируешь и прыгаешь между разными современными представлениями, это значит, что нужно много ждать. Это становится еще хуже, когда вы работаете с файлами и хотите проверить или обновить их. Оформление, регистрация и добавление в циклы контроля источника занимают около 10-15 секунд, что, очевидно, является кошмаром. Это очень раздражает, когда вы реорганизуете переименование / перемещение типов или методов (это может повлиять на многие файлы).

Отсутствие поддержки распределенной разработки

Сегодня разработка программного обеспечения часто является распределенной вещью (разработчики разбросаны по всему миру, работая над одним и тем же продуктом / проектом). ClearCase определенно не подходит для этого, потому что он плохо подходит для автономной работы. Выполнение проверки (действие перед тем, как вы сможете редактировать файл / папку) требует подключения к сети. Здесь вы можете использовать опцию hijack, но это скорее обходной путь как функция (вы просто разблокируете файл в файловой системе). Если ваши сайты разработки находятся далеко от вашего сервера ClearCase, задержка регистрации / отъезда может даже возрасти настолько резко, что ее вообще нельзя будет использовать. Для этого есть обходные пути, такие как использование ClearCase Multisite (технология реплики scm DB), но за это нужно платить, и администрация не является тривиальной задачей.

Git как альтернатива

Хотя я большой фанат + сторонник Open Source, я все еще готов платить деньги за хорошее программное обеспечение. Но, глядя на IBM-монстра ClearCase, я бы не стал вкладывать сюда свои деньги, у него есть все эти обсуждаемые недостатки, и, более того, IBM, похоже, не вкладывает деньги в существенное улучшение своего продукта. Недавно я посмотрел Git scm, который выглядит очень хорошо, особенно благодаря его функциям ветвления + слияния, где у ClearCase есть свои сильные стороны.

Эта информация взята с http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/

Источник

Возможно худшее программное обеспечение, когда-либо сделанное. Я не буду работать на какую-либо фирму, которая использует рациональные вещи. Помимо полного сбоя CC и частого перезапуска моей рабочей станции на динамических сборках. Что происходит, когда вы подталкиваете что-то к управлению исходным кодом, а CC делает то, что делает лучше всего, вылетает? Ваш код затем помещается в lost + found, возможно, где-то было выполнено резервное копирование? Нет, это ушло навсегда. Так что, если вы когда-нибудь попадете в ужасную ситуацию с использованием этого гигантского куска дорогого программного обеспечения, храните дубликаты всего. Хорошая работа Rational / IBM. Способ захвата наиболее важной части контроля источника, надежность. Умри медленно.

Источник

Недостатки ClearCase - дополнение к самому подробному сообщению здесь.

  1. Инструмент слияния не стоит. Он едва помогает вам, не помнит никаких решений, которые вы приняли, это просто прославленная разница.

  2. Инструмент слияния должен проверять каталоги, чтобы даже ПРОВЕРИТЬ, если они нуждаются в слиянии. Это немного безумно.

  3. Я использую BitKeeper на работе (допустим, Git), и объединение двух репозиториев, даже если есть конфликты, настолько тривиально и удобно для пользователя, даже с командной строкой, в то время как ClearCase с тоннами инструментов GUI является долгим и трудоемким процессом, который также чрезвычайно подвержен ошибкам,

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

  5. Кто-то может полностью испортить хранилище или проверки, если они делают спецификацию своего представления отличной от команды. Что совершенно безумно, что никто не может просто проверить какую-то ветку; им нужна соответствующая спецификация представления, которая, между прочим, даст им правильные вещи. Вся концепция может быть приятной и гибкой, но в 99% случаев она причиняет много боли. Я уже говорил, что вы не можете отправить свою спецификацию по электронной почте через Microsoft Outlook, поскольку инструменты CC не поддерживают UTF-8, поэтому вы не можете скопировать и вставить ее?

  6. Мне абсолютно нечего сказать про CC. Я использовал это в течение 2 лет в 2 компаниях и бросил это в сердцебиении, чувствуя себя счастливым все время. Также невозможно просто поэкспериментировать с вашими собственными проектами дома, так что вы все равно будете учить SVN или Git дома и будете вынуждены проходить через ClearCase на работе. Никто из тех, кого я знаю, никогда не использовал CC добровольно. Они используют его только потому, что какой-то менеджер на работе решил, что CC - это путь к спасению, и заставил всех мигрировать к нему. Фактически моя последняя компания перешла с CVS на ClearCase, а через год с ClearCase на SVN. Это было ненавистно.

  7. ClearCase это не просто одна вещь, которая заставляет вас говорить нет. Это как жить в доме, кишащем муравьями. Каждый муравей - в лучшем случае незначительное неудобство, но заражение сведет вас с ума.

Источник

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

  • Если вы сравниваете git и ClearCase, я с уважением утверждаю, что вам нужно лучше определить свои потребности - если вы рассматриваете ClearCase по "хорошей" причине, git, вероятно, даже не в уравнении - он слишком новый, чтобы доверять для управления источником на уровне предприятия, IMO.
  • ClearCase вводит множество концепций в пространство контроля версий, которого нет в других системах, поэтому это может быть довольно сложно и запутанно. Особенно, если у вас есть только опыт чтения документации, как, кажется, имеет место для нескольких человек здесь.
  • ClearCase определенно не подходит для огромных баз кода, поддерживаемых разработчиками, которые не находятся в локальной сети с сервером VOB. У вас может быть много реплицированных (многосайтовых) VOB-серверов, чтобы приблизить их к удаленным разработчикам, но это не обязательно практично, если эти удаленные сайты являются всего лишь одним разработчиком.
  • Хотите ли вы управление версиями файлов или хранилищ? Это довольно важный вопрос, который обязательно отфильтрует весь набор инструментов, упрощая вашу работу. Версионирование репозитория имеет много преимуществ (и оно не "новое", как утверждали некоторые авторы - коммерческие инструменты, такие как Perforce, существуют уже более десятка лет, и, возможно, были инструменты, которые делали версионирование репозитория еще до Perforce), но это не панацея
  • При достаточно большой установке любой системы контроля версий вам понадобится помощь. Рассматривая инструменты, вы должны подумать о том, как легко будет найти людей, которые могут вам помочь (или соискатели, которые имеют опыт работы, или консультанты, которые будут там в любой момент для решения любых вопросов). Нет такой вещи, как необслуживаемая система SCM, и если у вас есть такая система, вы столкнетесь с большим количеством проблем, чем выбор системы, которая требует "слишком большого" администрирования.
  • Не обращайте слишком много внимания на людей, которые говорят о том, насколько плохи "динамические представления" - плохие политики SCM плохие, независимо от того, какой инструмент вы используете. Ваши политики и практики управления конфигурациями должны быть отделены от вашего выбора инструмента - ни один инструмент не помешает людям разбить всю вашу кодовую базу, если вы не определите разумные политики ветвления и слияния. Если кто-то предполагает, что разработка разработчиков напрямую / main всегда является разумной идеей, вы можете отказаться от этого разговора.

ClearCase - прекрасный инструмент, но это сложный инструмент. Обойти это невозможно - в нем нет режима "простой установки".:-) С технической точки зрения git или SVN ничего не могут сделать, чего не может ClearCase (хотя зачастую терминология иная, поскольку проекты с открытым исходным кодом, как правило, просто изобретают новую таксономию там, где она уже существовала), но некоторые вещи определенно проще / сложнее для данной системы, в зависимости от их конструкции. Представления ClearCase "моментальные снимки" - это то же самое, что и при извлечении репозитория из SVN или CVS - это локальная копия исходного кода на вашем компьютере с указателями обратно на центральный сервер для инструментов для запроса истории версий. и т. д. Вы можете работать с этими представлениями без какого-либо сетевого подключения к серверу ClearCase после того, как они были созданы, и вы можете "перерабатывать" их, чтобы избежать повторной загрузки всего хранилища, когда вы хотите перейти к работе в другой ветви, для пример. "Динамические представления" - это в основном изобретение ClearCase и стандартный режим работы для локальной сети. Они выглядят так же, как при проверке репозитория SVN, но на самом деле они не копируют файлы, пока вы не внесете изменения. Таким образом, представление доступно сразу, но, очевидно, с ним нельзя работать, если основной сервер очистки недоступен и неприятно работать с соединением с высокой задержкой. Кроме того, они имеют удобство подключения к сетевому диску на любом компьютере с доступом к серверу, на котором они были созданы, поэтому, если ваша рабочая станция Windows умирает, вы можете просто войти на другой, смонтировать вид и получить Вернемся к работе, поскольку все файлы хранятся либо на VOB-сервере (для файлов, которые вы не изменяли в этой ветке), либо в view_server (для файлов, которые вы создали или изменили только в этом представлении).

Кроме того, и это заслуживает отдельного абзаца....clearmerge почти стоит одной цены за вход. Это лучший инструмент слияния, который я когда-либо использовал в своей жизни. Я твердо верю, что в SCM развилось много плохой практики из-за нехватки высококачественных инструментов слияния, поэтому пользователи CVS никогда не учились правильно использовать ветки, и этот страх перед ветвлением распространялся до сегодняшнего дня без особой уважительной причины.

Хорошо, несмотря на все сказанное, если вы ищете причины не использовать ClearCase, их не сложно найти, хотя я думаю, что это неправильный путь. На самом деле вам нужно найти веские причины для использования ClearCase, а не причины НЕ использовать ClearCase. Вам следует столкнуться с любой ситуацией в SCM, если предположить, что ClearCase - это слишком много или слишком сложный инструмент для работы, а затем посмотреть, не возникает ли у вас ситуация, которая побуждает вас его использовать. Наличие логотипов IBM или Rational не является хорошей причиной..:-)

Я бы даже не подумал о ClearCase, если бы вы не сказали "да" всем следующим утверждениям:

  • Сейчас у вас есть или будет в конечном итоге более 50 разработчиков, работающих над одной и той же кодовой базой.
  • Большинство из этих разработчиков расположены в центре или имеют высокопроизводительные соединения с низкой задержкой и центральным расположением.
  • У вас есть набор политик SCM, и вы можете определить, как использовать ClearCase для реализации этих политик (на самом деле, вы должны учитывать это для любого инструмента)
  • Деньги на самом деле не являются объектом
Источник

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

Помимо технической поддержки VCS, CC обладает рядом отличительных преимуществ:

  • Динамические представления
  • Хорошее дерево версий
  • Триггеры
  • Хорошее слияние версий, включая переименования

На мой взгляд, их использование ограничено, за исключением последнего; и они не компенсируют недостатки. Динамический вид приятен в теории, но не всегда доступен на практике. Дерево версий имеет гораздо меньшее применение в других VCS, но необходимо в CC из-за разрастания ветвей (см. 6). Триггеры, как я знаю, очень подробны и способны, но я думаю, что для большинства практических задач крючки SVN достаточно хороши. А теперь о недостатках, которые в основном касаются удобства использования:

  • CC полностью терпит неудачу в смысле удобства использования для основной группы пользователей: для разработчиков. И это главная причина, почему я думаю, что его никогда не следует использовать ни в какой среде, будь то предприятие или нет. Даже если бы он был бесплатным, он все равно высосал бы деньги вашей компании, тратя время ваших разработчиков и расстраивая их. Эта точка состоит из:
    1. "Check-Check-In" со строгим подходом к блокировке - это непродуктивно, рефакторинг недружелюбен и опасен в организациях репозитория с одной ветвью разработки для нескольких разработчиков. Между тем преимущества строгой блокировки незначительны.
    2. Низкая производительность и высокая нагрузка
    3. Это эффективно не может использоваться удаленно без мульти-сайта (из-за 2). Мультисайт тоже дорогой. Клиент ClearCase Remote очень ограничен. Это даже не имеет cleartool (до версии 7.1), оставив в покое динамические представления.
    4. Его вряд ли можно использовать в автономном режиме. Динамические представления просто не работают. Представления моментальных снимков эффективно доступны только для чтения, потому что вы не можете извлечь их без доступа к хранилищу (см. 1). Hijack - плохой вариант, который фактически означает, что CC снимает с себя ответственность за угнанный файл. И CC не может показать вам разницу с предыдущей версией в автономном режиме. SVN может показать разницу с предыдущей версией, даже находясь в автономном режиме.
    5. Слишком сложная модель, особенно с UCM: VOB, PVOB, Проекты, потоки, ветви, представления, доставка, обновление, загрузка, восстановление, перебазирование, объединение, базовый уровень, регистрация, проверка. Я думаю, что половина из этих концепций просто лишняя и не добавляет ценности, увеличивая при этом как техническую, так и концептуальную сложность. Немногие разработчики понимают даже основные вещи о CC.
    6. Распространение ветвей. Например, хранилище часто организовано с потоком на разработчика (из-за 1). Это просто не имеет смысла в SVN или большинстве других VCS.
    7. Нет репозитория широких ревизий. Ну, есть такие исправления, которые понимают, они называются базовыми. Но когда я вижу некоторую версию файла и хочу получить снимок репозитория в момент этой версии файла, у меня возникают некоторые проблемы. Мне нужно будет сделать черную магию со спецификацией конфигурации, чтобы создать представление снимка, или найти что-то через динамическое представление, если оно доступно.
    8. Дрянной пользовательский интерфейс. Дерево версий, даже будучи хорошим, имеет посредственное удобство использования. Инструмент слияния просто жаль. Другие "особенности": не изменяемые размеры окон, отсутствие пошагового поиска в некоторых местах, ориентированный на мышь интерфейс, внешний вид в стиле 1995 года, странный рабочий процесс, распределяемый между Client и Project Explorer и т. Д.
    9. CC провоцирует редкие и обширные проверки. Вы все знаете, что проверки должны быть небольшими и частыми. Но разработчики обычно воздерживаются от дополнительных взаимодействий с CC, захватом файлов и работой в локальной VCS или вообще без VCS (что чаще всего, к сожалению). И затем, после двух недель разработки, они начинают коммитить функцию, которая добавляет 20 файлов и затрагивает еще 20 файлов. Это длится в течение дня или двух, потому что они похитили файлы и теперь должны выполнить слияние вручную со всеми новыми изменениями из репо и разрешить все конфликты и несоответствия. Во время этого процесса код не компилируется, потому что несколько файлов были успешно проверены, а другие нет. И после этого он все еще не компилируется, потому что они забыли добавить еще 2 файла в CC.
  • Это очень дорого
  • Это очень сложно с точки зрения инфраструктуры и требует выделенных администраторов
Источник

ClearCase кажется чрезвычайно мощным, со стороны. Но на самом деле, просто количество команд и опций, которые вам нужно использовать для базового рабочего процесса, настолько велико, что они скрываются за несколькими псевдонимами или сценариями, и в результате вы получаете нечто менее мощное, чем CVS, с удобством использования Visual Source Безопасный. И всякий раз, когда вы хотите сделать что-то более сложное, чем позволяют ваши сценарии, у вас возникает тошнота в желудке.

Сравните это с Git, который кажется сложным снаружи, но после недели работы с ним вы чувствуете себя полностью под контролем. Модель хранилища проста для понимания и невероятно мощна. Поскольку легко разобраться с гайками и болтами, на самом деле приятно копать под поверхностью вашего ежедневного рабочего процесса.

Например, выяснение тривиальной задачи, такой как просмотр не-HEAD-версии файла в виде снимка, заняло у меня пару часов, и в результате я получил полный хак. Не приятный вид взлома либо.

Но в Git выяснить, казалось бы, сложную задачу, например, как интерактивно зафиксировать только некоторые изменения (и оставить остальное на потом), было очень весело, и все время у меня возникает ощущение, что VCS позволяет мне организовывать код и история меня устраивает, а не случайность того, как мы использовали VCS. "Git означает никогда не говорить" ты должен иметь "".

На своей работе я использую Git для всех видов легких задач, даже в ClearCase. Например, я делаю TDD, и я обязуюсь использовать Git всякий раз, когда проходит куча тестов, и я собираюсь провести рефакторинг. Когда задача в конце концов выполнена, я регистрируюсь в ClearCase, и Git помогает мне просмотреть, что именно я изменяю. Просто попробуйте получить ClearCase для создания различий между несколькими файлами - это невозможно! Используйте Google, чтобы узнать, какие хаки люди пытались обойти. Это то, что контроль версий должен делать из коробки, и это должно быть легко! CVS имел это в течение десятилетий!

Источник
  • Кошмар для администрирования в безопасных условиях
  • Устаревшие технологии
  • Неинтуитивный графический интерфейс
  • Дорого
  • Ресурс монстра
  • Распродажа в Microsoft

По моему мнению? Единственная причина иметь это? Если вы неукоснительно следите за RUP.

Источник

Поддержка ужасна. У нас были билеты, открытые в течение многих лет. Наш гуру затмения фактически исправил ошибку в своем плагине eclipse локально за 30 минут, разобрав файл java. Но билет до сих пор не получил поддержку первого уровня. Время от времени они либо пытаются скрытно закрыть его, либо отправляют нам запрос "попробовать последнюю версию" (хотя мы отправили им рецепт воспроизведения, который они могли бы попробовать сами).

Не прикасайтесь к столбу баржи.

Источник

Спектакль.

ClearCase является мощным, стабильным (если его правильно поддерживать и контролировать), но он медленный. Геологический иногда.

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

Источник

Clearcase настолько раздражает, что фактически заставляет людей писать стихи об этом:

http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html

http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/

Источник

  • Разработчики потратят половину своего времени на изучение clearcase, прежде чем выполнять какую-либо работу, и, как только они это выяснят, они установят git локально и будут загружать репозиторий clearcase только по мере необходимости.

  • Вам придется нанять специального администратора Clearcase.

Источник

Я бы предложил SVN для набора инструментов и Git для масштабирования / рабочего процесса. Я также предложил бы избегать CC, где это возможно. (Не считая денег, тот факт, что это такая боль в использовании, которая требует администратора на полный рабочий день, это полная шутка)

Источник

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

Команда, в которую я был недавно назначен, использовала тяжеловесный инструмент в замысловатой, подверженной ошибкам манере. Сначала я попытался продать их на своих инструментах и ​​процессах выбора. Эта попытка с треском провалилась. Я был ошеломлен тем, что они выберут такую ​​обременительную среду, которая была бы проще и эффективнее. Оказывается, что они хотели быть дисциплинированными, и используя болезненный процесс чувствовал себя дисциплинированным к ним. Звучит странно, но это правда. У них тоже было много других заблуждений. После того, как я выяснил, к чему они стремятся, мы фактически остановились на одном и том же наборе инструментов (Serena), но существенно изменили его настройку.

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

Источник

Я не полностью против ClearCase (у него есть свои преимущества), но перечислю недостатки:

  • Ограничения лицензии - я не могу легко работать из дома, потому что у меня нет доступа к серверу лицензий. Даже при наличии снимка экрана на моем ноутбуке мне приходится играть с трюками, потому что я не могу получить лицензию. Существует специальный удаленный клиент, но он добавляет массу своих ограничений
  • Ограничения лицензии снова - Только так много мест, чтобы обойти, и тогда никто не может использовать его.
  • Инструменты Unix устарели - ClearCase, кажется, лучше всего работает в системах Unix, но инструменты GUI отстой. Интеграция ClearCase в Windows/Unix привносит в себя все виды трудностей.
Источник

ClearCase отлично подходит для использования, если вы хотите использовать другую систему контроля версий поверх него! лично я нахожу, что использование Mercurial Ontop of CC работает достаточно хорошо.

Источник
  1. нет атомных проверок

Начиная с новой версии версии 7.1 CC предоставляет элементарную регистрацию как функциональность, если вам это нравится. Лично я действительно не хотел бы этого, но, видимо, некоторые люди видят в этом "существенную особенность". Я НИКОГДА не хотел бы, чтобы одна большая масса за один раз была своего рода массовой версией. С другой стороны... если хочешь, просто включи.

так что... больше не спор.

Источник

Самым большим недостатком для меня является как производительность (особенно если ваш VOB многоузловой или удаленный), так и потенциально длительные простои.

Если вы похожи на меня и работаете в сравнительно небольшом офисе в составе большой компании (без ИТ-подразделений на месте), отказ серверов Clearcase может стоить вам большую часть рабочего дня в непроизводительной сфере, а также привлечение нужных людей. чтобы исправить это.

В итоге, используйте его только в том случае, если он вам действительно нужен для того, что вы делаете, и убедитесь, что у вас есть надежный ИТ-бюджет для его обслуживания.

Источник

Мы использовали UCM ClearCase, интегрированный с ClearQuest (система отслеживания / изменения DR) за последние 4 года с более чем 50 разработчиками. У нас более 50 проектов UCM, более тысячи потоков, которые обрабатывали более 35 тыс. DR и запросов на изменение. За этот период мы официально осуществили более 600 интеграционных поставок и одновременно провели до 6 одновременных усилий по разработке и выпуску.

Я основной парень CM/ClearCase с резервной копией, который может выполнять регулярные сборки доставки / слияния и интеграции. Сеть и серверы поддерживаются ИТ-командой. Все, что я могу сказать, это то, что у нас практически не было проблем со стороны CM в этом огромном усилии по разработке, и мы никогда не были ограничителем шоу. Наши разработчики обучались только базовым вещам и простым шагам, которые им давали всякий раз, когда новый проект (филиал) создавался по запросу руководства проекта.

Слишком много разработчиков жаловались на ClearCase, потому что им не хватает надлежащей поддержки CM/IT/ClearCase/Process/Management. Разработчики должны сосредоточиться на разработке, а не на SCM или быть специалистом по инструментам. Для крупной разработки программного обеспечения, как минимум, 5-7% бюджета должно быть потрачено на поддержку CM и инструментов.

Источник

Точка "это нуждается в выделенном человеке" и "это сложно" и т. д....

Основная проблема, возникающая при нахождении этой проблемы, заключается в том, что вы должны определить, хотите ли вы, чтобы управление конфигурацией выполнялось в вашей организации (а не управление версиями). Управление конфигурациями похоже на управление проектами: даже без инструмента вы все равно можете управлять проектами, а без инструмента вы можете управлять конфигурацией. Многим людям трудно понять это, и многие думают, что Configuration Management - это инструмент, который устанавливает версии программного обеспечения или чего-то еще... (следовательно, сравнение с Subversion или другими системами управления VERSION)

ClearCase - это решение, созданное для использования в среде управления конфигурациями ERGO: есть менеджер конфигурации (как "менеджер проекта").

Так что... если, по вашему мнению, этот преданный человек существует для управления инструментом, я думаю, что-то очень неправильно. В моем восприятии есть специальный человек, который занимается управлением конфигурацией, который с точки зрения конечного пользователя появляется только тогда, когда есть проблема с инструментом, но считает, что это только 1% его работы.

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

И ИМХО, если у вас есть список требований организации И менеджер конфигурации в смеси.... выбор довольно ясен (см. Также форум на www.cmcrossroads.com)

ClearCase - это не инструмент только для конечных пользователей, которые вводят свои источники под управлением версиями, такими как subversion или git. Это всего лишь 1% того, почему диспетчеру конфигурации действительно нужен зрелый инструмент управления конфигурацией.

И... я думаю, что выбор системы CM никогда не должен зависеть от разработчиков, равных выбору правильного инструмента управления проектами или правильной системы CRM. Разработчики являются конечными пользователями определенной части функциональности инструмента.

Источник

Запуск JDK из VOB в Linux.

Попробуйте, вам нужно поиграть с переменной LD_PRELOAD (я знаю!)

Источник

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

К сожалению, это идет с ценой, большой ценой. Это дорого, и для правильной работы необходимо правильно настроить и поддерживать специальную команду ИТ. Это делает его действительно хорошим для BigCo, но не таким мудрым выбором для SmallFirm.

Я большой поклонник DVCS и git, но могу понять, почему BigCo выбрал ClearCase вместо SVN и Git. Что я не могу понять, почему кто-то выбрал SVN вместо Git;>

Источник

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

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

Другой - это мгновенный доступ к исходному коду и измененным файлам, при этом ничего не тратится на скачивание.

Он служит хорошо для той цели, которая у него есть.

Источник
Другие вопросы по тегам