Итак, позвольте мне описать нашу текущую ситуацию. Мы небольшая команда (6) опытных Java-разработчиков, затерявшаяся в большой команде информационных систем, в большинстве своем состоящей из конфигураторов SAP и Siebel.
В то время как все другие команды в настоящее время используют VSS, в основном в качестве системы хранения, наша команда переключилась на Subversion (также после оценки DVCS), поскольку это лучше всего соответствует нашей гибкой методологии.

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

Вот как мы сейчас работаем ежедневно:

  • Репозиторий SVN следует структуре / trunk, / branch, / tags.
  • У каждого разработчика есть собственная песочница в репозитории для целей тестирования и прототипирования.
  • Мы интенсивно используем ветки для разработки новых функций и используем их для объединения их вместе, чтобы провести некоторое интеграционное тестирование, прежде чем возвращать их обратно в основной канал.
  • Работая на Java, мы привыкли проводить рефакторинг, и Eclipse нам в этом очень помогает. Каждый день происходит переименование множества классов и пакетов.
  • В зависимости от того, как развивались проекты, некоторые части могут быть использованы повторно, что приведет к разделению проекта на несколько проектов, при этом оригинал остается интегрированным через свойство svn: external.
  • Мы используем замену ключевых слов для некоторых элементов, поскольку это чрезвычайно простой способ узнать, какую версию он тестирует.
  • Наш репозиторий Subversion связан с Hudson для запуска наборов тестов и продвижения действительных сборок, помечая их.

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

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

Спасибо.

3
gizmo 11 Авг 2009 в 11:54

6 ответов

Лучший ответ

Во-первых, вот несколько сообщений о ClearCase, которые вы могли прочитать:

Нво:

  • CCRC означает «веб-представления», то есть представления моментальных снимков на выделенном для ClearCase веб-сервере ... вам лучше иметь хорошую локальную сеть между вашим рабочим столом и этим сервером.

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

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

  • подключаемый модуль ClearCase Eclipse поддерживает рефакторинг.

  • понятие svn: external на самом деле не поддерживается в ClearCase, кроме как через ссылки. Или с помощью базовых зависимостей UCM.
    Следует знать, что с зависимостями двоичных файлов легче работать, чем с зависимостями источников: если ваш внешний предназначен для включения тысячи исходных файлов следующего проекта, это будет громоздко в ClearCase (из-за долгих обновлений). Если вы включите несколько jar или dll, это будет намного быстрее (плюс те, которые будут фактически развернуты).

  • Если вы работаете с UCM, переместить коды из одного компонента в другой будет невозможно. Вам нужно будет clearfsimport < / a> основные метки в новом идентифицированном "общем" компоненте.

  • Примечание. Подстановка ключевых слов RCS обычно ... зло;) Я бы порекомендовал отдельный текстовый файл с версией или метками соответствующих важных файлов в нем. Это отлично подходит для материалов доставки, а не для исходных файлов.

3
Community 23 Май 2017 в 12:19

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

У нас в команде очень плохие времена с CC. Наши администраторы работают удаленно и изолированы от остальной команды, поэтому мы вынуждены общаться с ними через электронную почту и трекер запросов. Представляете, сколько на это уходит времени. Мы не можем обновиться до последних версий CC из-за дороговизны и сложности этого процесса (и, я думаю, из-за некоторой административной нагрузки). Итак, мы используем CC / CCRC версии 7.0.

CCRC этой версии полностью отстой. С ним нелегко провести рефакторинг. Вы не можете выполнить произвольное слияние с ним. Вы не можете создать базовый план. Вы даже не можете поместить файлы в список игнорируемых. Кстати, насколько мне известно, CC поддерживает игнорируемые файлы только в последних версиях CCRC, а не в собственном клиенте CC. Наша версия CCRC вообще не имеет интерфейса командной строки.

CC сильно зависит от связи с сервером, и по этой причине CC (и CCRC) оставляет разработчика самостоятельно, когда он пытается работать в автономном режиме. Репозиторий CC не может использоваться удаленно без CCRC или удаленного рабочего стола (время отклика на щелчок мыши составляет порядка минуты).

CC мешает работе других инструментов, поскольку помечает все файлы как доступные только для чтения и требует их явного извлечения перед изменением. Итак, имея плагин Eclipse, вы можете провести рефакторинг. Но с любым другим инструментом вам не повезло. Вам нужно будет проверить файлы перед этим или принудительно изменить их, превратив таким образом их в захваченные. Если вы используете другую среду IDE, сценарии sed или awk или что-то подобное, у вас возникнут проблемы. И даже если вы используете только Eclipse, операции с CC (то есть все рефакторинги переименования и т. Д.) Будут медленными, потому что CC медленный.

Единственное, что хорошо в CC, это то, что он хорошо справляется с слиянием и отслеживанием слияния. Но Subversion 1.5 довольно близко подошла к этому моменту. И вообще, это не покупает меня на использование CC.

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

И, кстати, я предполагаю, что IBM Rational рано или поздно переведет своих клиентов на платформу Jazz. Его Rational Team Concert - это что-то с «привкусом гибкости». У него есть бесплатная версия для 10 разработчиков и некоторая интеграция с CC (но не уверен, что это тоже бесплатно). Так что вы можете попробовать. Но я не верю ни во что хорошее от IBM Rational.

3
Rorick 11 Июл 2010 в 02:49

Проблема с ClearCase:

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

ClearCase был отличным ответом. Представления могут жить на сервере представлений. VOB находятся на сервере Vob. Выделенные машины: быстрые, быстрые, быстрые.

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

Кроме того, структура VOB ClearCase означала, что вы могли делать то, что могли делать немногие системы контроля версий. Например, вы можете cd в файле, если вы добавите @@ к имени. Это позволило вам увидеть все ветки, теги и все версии этого файла. Вы можете просто запустить свои стандартные инструменты Unix для поиска различий и т. Д.

Затем мир изменился:

  • Настольные системы стали более мощными. У вас есть дисковое пространство, память и чистая вычислительная мощность. Создание рабочей области проверки на вашем локальном диске (а она у вас определенно была) означало, что вам не нужно было зависеть от сети, которая становилась все медленнее по мере появления все большего и большего количества сетевых процессов. Подмигнуть в производном объекте? Черт возьми, моя машина могла построить присоску в пять раз быстрее, чем ClearCase может найти соответствующий производный объект.

  • Windows. ClearCase разрабатывался с учетом требований Unix. Хуки могут работать в локальной системе, потому что у всех на рабочем столе установлен Perl, и вы можете легко убедиться, что все они имеют одну и ту же ревизию. Черт возьми, у вас может быть смонтированный NFS каталог / usr / local (я знаю, но сетевые каталоги local были обычным явлением) с правильной версией Perl или чем-то еще, и ваши ловушки будут работать. Windows играла не так хорошо. Крючки стали головной болью.

  • Опять Windows: для хорошей работы ClearCase зависел от инструментов Unix. В Windows их не было.

  • Гибкая разработка: при разработке ClearCase модель разработки заключалась в изоляции разработчиков друг от друга. Вы могли бы работать намного быстрее, если бы вам не приходилось постоянно беспокоиться о том, что другой разработчик внесет изменения в вашу систему. В ClearCase ветвление было простым. Вы можете дать каждому отдельную ветку, а затем они смогут снова слиться с основной веткой, когда они будут готовы. Сливайся туда-сюда! В ClearCase это просто. Черт возьми, UCM построен на самом фундаменте. К сожалению, стратегия требовала полной дисциплины. Вы должны были постоянно напоминать разработчикам о необходимости объединить их код, чтобы другие разработчики могли их видеть. Неизбежный кризис слияния произошел прямо перед выпуском, когда десятки разработчиков все пытались объединить свои изменения обратно в ветвь интеграции. Гибкая разработка устраняет концепцию изоляции разработчиков. Вы вносите небольшие изменения и следите за тем, что делают другие. Таким образом, концепция «Ветвления Опры» (Вы получаете ветку! Вы получаете ветку! Каждый получает ветку!) Больше не используется.

  • Итак, теперь у вас есть быстрая система с большим количеством дискового пространства и памяти. У вас может быть три или четыре отдельных кассы одновременно. Преимущество динамического просмотра просто не преодолело его недостаток - медлительность и интенсивность работы в сети. Представления моментальных снимков помогают, но они удаляют все волшебство ClearCase, которое когда-то было. Другими словами, зачем использовать такую ​​большую и громоздкую систему, как ClearCase, как это было с CVS, если можно просто использовать CVS?

  • Наконец, ClearCase сложен. В старые времена, когда все разработчики были экспертами в области систем и сетей, можно было ожидать изучения тонкостей ClearCase. Создавать представления было не сложнее, чем изучать синтаксис YACC. Однако разработчики не так разбираются в системе, как раньше. Зачем им быть? Вам не нужно знать, как работает память, чтобы программировать на Java или C #. Разработчики больше не хотят изучать около 100 различных инструментов для выполнения своей работы. Обучение ClearCase может занять несколько дней, а изучение тонкостей ClearCase может занять недели. В ClearCase мне нужно понимать синтаксис представления, чтобы делать простые вещи, например изменять код в ветке. В CVS это всего лишь одна команда.

ClearCase просто слишком сложный, медленный и дорогой. И, по большей части, Atria сделала ставку на создание ClearCase: 1). Разработчики захотят изучить его, потому что им в любом случае придется изучить еще 100 инструментов. 2). Ваш настольный компьютер медленный и крошечный по сравнению с сетевыми серверами. Делать все «в облаке» быстрее. 3). Возможности централизации ClearCase являются большим преимуществом для компаний, поскольку один сайт может управлять всем и поддерживать все.

Все три предположения оказываются ложными, и из-за этого все меньше и меньше компаний даже рассматривают ClearCase. Может быть, когда Rational купила PureAtria, если Rational перенесет ее в 21 век, чтобы сделать ее меньше, легче и дешевле, она все еще могла бы быть широко используемым инструментом. Но Rational была слишком занята, делая разработку более запутанной, чтобы интегрировать все изящные инструменты, которые они купили, в централизованный процесс разработки. К тому времени, когда IBM купила Rational, ClearCase начал истощать пользователей.

3
David W. 20 Дек 2010 в 17:10

Штуковина,

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

CCRC рекламируется как инструмент для разработки Java. Я не совсем уверен, что верю - CCRC (Удаленный клиент ClearCase) был разработан для помощи разработчикам, работающим удаленно из основной инфраструктуры. Код сохраняется на рабочем столе, чтобы ускорить доступ, но есть накладные расходы, связанные с проверкой входа и выхода, которые нельзя игнорировать.

Рефакторинг технически возможен из CCRC, но невозможно выполнить рефакторинг, если он отключен от инфраструктуры - инструмент не позволит вам.

Существуют также другие проблемы с рабочими пространствами Eclipse, которые хорошо сочетаются с представлениями CCRC - у вас могут быть (в зависимости от структуры ветвления вашей среды) проблемы с абсолютными путями для инструментов.

Следует иметь в виду - и, возможно, изучить, - что ClearCase действительно поддерживает просмотр снимков в обычном режиме. Я не согласен с VonC (возможно, впервые в жизни он адский админ) в том смысле, что я считаю, что представления CCRC (которые называются веб-представлениями) сильно отличаются от собственных представлений моментальных снимков, которые позволяют вам развиваться в среде, которая больше похожа на SVN - особенно если вы хотите заниматься Java-разработкой.

Что касается ClearCase и Hudson, я поговорил с Эндрю Байером о том, чтобы плагин ClearCase работал немного проще с динамическими представлениями, которые вошли в игру в версии 0.9. Он довольно активный член сообщества Hudson, поэтому, если у вас есть проблемы с плагином, возникшие проблемы должны быть исправлены довольно быстро.

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

Удачи!

Стюарт

2
Spedge 12 Авг 2009 в 12:37

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

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

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

Но мне не ясно, будет ли все ваше взаимодействие с Clearcase только через CCRC (удаленный клиент Clearcase). Я не использовал CCRC и не знаю, что все поддерживается через CCRC.

1
sateesh 11 Авг 2009 в 08:17

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

0
Dewfy 11 Авг 2009 в 08:00