Каковы основные clearcase понятия, которые должен знать каждый разработчик? [закрытый]

ClearCase является зверем для использования. Медленный, ошибочный, и дорогой. Некоторые вещи, которые я сделал для преодоления использования CC:

1. Всегда помещает хорошие комментарии, когда Вы регистрируетесь.
2. Использование общая спецификация конфигурации и не изменяют его очень часто.
3. Никогда попытка не использовать CC по VPN или замедлить сетевое соединение.
4. Выключают загрузку от доктора CC на запуске.
5. не перемещают файлы к различным каталогам.
6. Расписание по крайней мере 2 минуты на файл для регистрации.
7. представления Снимка являются медленными, но динамические представления медленнее.
8. Делают привычку разработки к регистрации рано и часто потому что зарезервированные файлы и слияния являются болезненными.
9. Имеют все файлы выезда разработчиков в незарезервированном по умолчанию.

ПРАКТИЧЕСКОЕ РУКОВОДСТВО Управления исходным кодом Eric является замечательным гидом, который Независим от инструмента.

Я работал с clearcase к лучшему часть 6 лет и обычно находил это терпимым. Это действительно имеет определенную кривую обучения, но как только Вы привыкаете к причудам, можно в значительной степени работать гладко с ним. Очень компетентный администратор CC, который знает то, что он делает, важен для чего-либо кроме тривиальных установок. Если Вы не имеете один, люди собираются столкнуться с проблемами и достаточно скоро будет разговор о проблеме "ClearCase". Тогда управление должно будет вмешаться путем переключения на что-то еще вызывающее только пустую трату времени для всех вовлеченных. CC не является плохим продуктом, Он просто иногда плохо понимается.

Вот немного понятий, которые я нашел важным, некоторые из них не являются полностью CC, только ориентированным -

• , контроль А непохож на регулярное подобное CVS понятие контроля. Когда Вы проверяете Вас, блокируют файл до Вас регистрация это в.
• нет никакой проблемы с движущимися файлами. заразите это работает безупречно.
• деревья Версии важны для понимания, что происходило с файлом. Они могут стать довольно грязными для активных файлов, но когда Вы привыкаете к наблюдению их, это становится очень полезным инструментом и Тем, которому очень недостает других инструментов управления исходным кодом, таких как SVN (в некоторой степени).
• не используют динамические представления ни при каких обстоятельствах. не стоящий того.
• прежде, чем сделать новое ответвление, поток или проект, советуются с Вашим администратором, чтобы удостовериться, что то, что Вы создаете, действительно, что будет служить Вам лучше всего. При запуске новой кодовой базы удостоверьтесь, что Вы получаете расположение потоков и проектов с самого начала путем планирования заранее. изменение его позже является реальной головной болью, если даже возможно.
• Точная настройка полномочия пользователей и настроенных триггеров для общих событий, чтобы предотвратить частые ошибки или осуществить политики. Сервер очень настраивается и большинство для проблем, с которыми Вы встречаетесь существует, вероятно, разумное решение.
• рассказывают разработчикам о чем-либо от фундаментальных понятий совершенствовать операции. Продвинутый пользователь, который может найти то, что проблема использует cleartool, понижает нагрузку на администратора.
• не покидают повисшие потоки и представления. Когда разработчик уезжает, проект имеют кого-то для удаления всех представлений, которые он имел на своей машине, и удалите все его частные потоки. Не содержание в чистоте Вашего сервера приведет к... этому являющийся грязным и со временем, медленное. Когда Вы делаете, "находят весь контроль" на всех потоках и представлениях, Вы не должны видеть файлы, которые проверяются людьми, которые больше не существуют.
• Мандат "всегда переоснова прежде поставляет" политику для дочерних ответвлений для ухода от людей "повреждение потока интеграции" при поставке кода, который конфликтует с недавними изменениями.
• Непрерывная интеграция - не позволяют потоку интеграции застояться в то время как каждый разработчик или работа в команде на их собственном ответвлении. Мандат один раз в X раз, когда все должны по крайней мере повторно базироваться к новой базовой линии интеграции, если не обеспечить их стабильные изменения. Это действительно очень трудно сделать, особенно с крупными проектами, но другая альтернатива является "адом интеграции", где в конце месяца никто ничего не делает в течение 3 дней, в то время как некоторые попытки бедняги внести все изменения совмещаются

По-моему, ветвление и слияние являются самыми важными понятиями в любой системе управления исходным кодом (рядом с самим управлением версиями, конечно).

, Как только Вы понимаете, как это сделало (и Clearcase делает это очень хорошо, до такой степени, когда мы делаем даже небольшие изменения как ответвление и переслияние, не что-то, что я когда-либо делал бы с RCS или CVS), Вы найдете, что Ваша жизнь сделана намного легче.

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

Мы использовали CC в течение чуть более чем пятнадцати лет теперь. Это имеет много хороших функций.

Вся наша разработка сделана на ответвлениях; я создал пару сегодня для нескольких различных наборов изменений. Когда я зарегистрировался в ответвлении, я заставил коллегу рассматривать изменения и затем объединился назад в/main/LATEST - который, оказывается, куда моя работа должна была пойти. Если бы это было для более старого выпуска на ответвлении, то это не было бы немного тяжелее.

Слияния от моих временных ответвлений были полностью автоматическими; никто не изменил файлы, я продолжил работать, в то время как мне проверили их. Хотя контролем по умолчанию резервируются (заблокированные), Вы можете всегда несдержанность контроль позже, или создавать незарезервированный контроль. Когда изменения берут в несколько дней, пересинхронизация моего временного ответвления с основным ответвлением является легкой и обычно автоматической. mergetool в порядке; самая большая проблема для меня состоит в том, что моя машина сервера составляет приблизительно 1 800 миль от моего офиса (или домой), так, чтобы X, по которому удаленный является немного медленным (но весьма терпимо так). Я не использовал лучший mergetool, но это не может говорить многое, так как я не использовал никакой другой графический mergetool.

Представления (динамические представления) быстры на нашей установке. Я не использовал представления снимка, но я не работаю над Windows, когда я могу помочь ему (наши представления снимка использования команды о Windows; я не ясен почему). У нас есть сложные ветвящиеся системы, но основная разработка сделана на/main/LATEST, и работа выпуска сделана на ответвлении. После GA работы по техническому обслуживанию сделаны на выпуске определенное ответвление и объединены вперед с/main/LATEST (через любые промежуточные версии).

CC действительно нужны хорошие администраторы - мы имеем их и повезли при этом.

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

Я не вижу, что офис переключает с CC любое время.

Встроенные номера версий - хороший или злой?

Я записал:

Самая большая проблема, которую я имею с CC, состоит в том, что он не встраивает номера версий в исходные файлы - проблема, которую мерзавец имеет также, AFAICT. Я могу половина видеть почему; я не уверен, что мне нравится бросать ту отслеживаемость, все же. Так, я все еще использую RCS (даже CVS) для большей части моей персональной работы. Однажды, я могу переключиться на мерзавца - но это будет толчок, и потребуется большая работа для переоборудования систем выпуска, настроенных вокруг (SCCS и) RCS.

В ответ, @VonC примечания:

Мы всегда полагали что практика как зло (смешивание информации о метаданных в данные), представляя "ад слияния". См. также, Как получить версию файла Clearcase в файле Java. Конечно, можно использовать триггер для замены ключевого слова RCS (Руководство Clearcase: Триггерный Пример Регистрации), если Вы используете соответствующего менеджера по слиянию.

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

Фон

Я изучил SCCS назад в 1984 во время, RCS был выпущен (1983, я верю), но SCCS был на моей машине, и Интернет был возникающим в лучшем случае Я переместился от SCCS до RCS неохотно в середине 90-х, потому что формат даты SCCS использует двузначные цифры в течение многих лет, и не было ясно, будет ли SCCS универсально зафиксирован вовремя (это было). В некотором отношении мне не нравится RCS целый SCCS, но он имеет некоторые положительные стороны. Коммерчески, мой работодатель использовал SCCS до середины 1995, но они начали переключать к Атриумам ClearCase с начала 1994, занявшись наборами отдельного продукта по одному.

Ранний эксперимент ClearCase с триггерами - и ад слияния

Наш проект мигрировал позже, когда уже был некоторый опыт с CC. Частично, потому что я настоял на нем, мы встроили информацию об управлении версиями в исходные файлы через триггер регистрации. Это продлилось некоторое время - но только некоторое время - потому что, как VonC заявляет, это ведет для слияния ада. Проблема состоит в том, что, если версия с тегом/main/branch1/N объединяется с/main/M от общей базовой версии/main/B, извлеченные версии файлов содержат одну строку, которая имеет редактирования в каждой версии - конфликт. И тот конфликт должен быть разрешен вручную, вместо того, чтобы быть обработанным автоматически.

Теперь, SCCS имеет идентификационные ключевые слова. Идентификационные ключевые слова берут два формата, один для отредактированных файлов и один для файлов, которые не редактируются:

Edit         Non-Edit
%I%          9.13
%E%          06/03/09
%Z%          @(#)
%M%          s.stderr.c

Если бы Вы делали попытку слияния с 3 путями доступных для редактирования версий файлов SCCS (с %x нотацией %), то не было бы никаких конфликтов на строках, содержащих метаданные, если Вы не изменили метаданные по тем строкам (например, путем изменения от американского стиля %D дат % к британскому стилю %E даты % - SCCS не поддерживает стиль ISO 15.03.2009 дат как стандарт.)

RCS также имеет механизм ключевых слов, и ключевые слова также берут два формата, хотя каждый для файлов, которые еще не были вставлены в RCS, и другой для тех, которые имеют:

Original       After insertion
$Revision$     $Revision: 9.13 $
$Date$         $Date: 2009/03/06 06:52:26 $
$RCSfile$      $RCSfile: stderr.c,v $

Различие между '$' после ключевого слова и a ':', пространство, текст, пространство и наконец '$'. Я не сделал достаточного слияния с RCS, чтобы быть уверенным, что это делает с информацией о ключевом слове, но я отмечаю, что, если это рассматривало обоих расширенные и 'законтрактованные' нотации как эквивалентных (независимо от содержания расширенного материала), затем слияние могло произойти без конфликта, оставив законтрактованную нотацию в выводе слияния, которое будет соответственно расширено, когда получающийся файл будет получен после регистрации.

Проблемой ClearCase является отсутствие соответствующего менеджера по слиянию

Как я указал в своем обсуждении SCCS и RCS, если слияние с 3 путями сделано, рассматривая ключевые слова в корректном (законтрактованный или доступный для редактирования) форматы, то нет никакого конфликта слияния.

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

Если была система для обработки ключевых слов и соответствующего менеджера по слиянию, то:

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

Оборотная сторона этого - то, что это требует или специального инструмента различия, который распознает маркеры метаданных и рассматривает их особенно, или это требует, чтобы файлы, питаемые к инструменту различия, были каноническими (маркеры метаданных уменьшаются до нейтральной формы - $Keyword$ или %K % в RCS и условиях SCCS). Я уверен, что это немного дополнительной работы - причина, почему она не поддерживается, что-то, что я всегда чувствовал, было близоруко в такой мощной системе. У меня нет конкретного вложения к RCS или нотаций SCCS - нотации SCCS легче обработать в некотором отношении, но они чрезвычайно эквивалентны - и любая эквивалентная нотация могла использоваться.

Почему я все еще думаю, что метаданные в файле хороши

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

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

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

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

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

Так, это - умеренная сводка того, почему мне нравится встраивать информацию о версии в исходные файлы. Это является в значительной степени историческим - SCCS и RCS и сделало это, и мне понравилось то, что они сделали. Это может быть древний пережиток, что-то, чтобы попрощаться в эру DVCS. Но я полностью еще не убежден этим. Однако могло бы потребоваться еще больше эссе для объяснения входов и выходов моего механизма управления версиями для наблюдения, почему я делаю вещи, как я делаю.

Один аспект обоснования - то, что файлы ключей, такие как 'stderr.c' и 'stderr.h', используются по существу всеми моими программами. Когда я выпускаю программу, которая использует его, я просто удостоверяюсь, чтобы у меня была новая версия - если не было интерфейсное изменение, которое требует задней версии. У меня не было той проблемы некоторое время теперь (я сделал систематическое переименование в 2003; это вызвало некоторые переходные головные боли, но сценарии Perl позволили мне реализовывать переименование довольно легко). Я не знаю, сколько программ использует тот код - где-нибудь между 100, и 200 было бы справедливое предположение. Набор этого года изменений (ряд версии 9.x) является все еще несколько спекулятивным; я наконец не решил, сохранить ли их. Они являются также внутренними к реализации и не влияют на внешний интерфейс, таким образом, я просто еще не должен решаться. Я не уверен, как обработать того мерзавца использования. Я не хочу встраивать код библиотеки в библиотеку, которая должна быть установлена, прежде чем можно будет создать мое программное обеспечение - это слишком обременительно для моих клиентов. Так, каждая программа продолжит распределяться с копией кода библиотеки (другой вид обременительных), но только код библиотеки, в котором программа нужна, не целая библиотека. И я привередничаю для каждой программы, какие библиотечные функции используются. Так, я не экспортировал бы целое поддерево; действительно, фиксация, которая покрыла последние изменения в коде библиотеки, обычно абсолютно не связана с фиксацией, которая покрыла последние изменения в программе. Я даже не уверен, должен ли мерзавец использовать один репозиторий для библиотеки и другого для программ, которые используют его, или общий репозиторий большего размера. И я не буду мигрировать на мерзавца, пока я действительно не пойму это.

Хорошо - достаточно болтовни. Что у меня есть работы для меня; это не обязательно для всех. Это не требует у VCS - но это действительно требует метаданных версии, встроенных в файлы, и CC и Мерзавца и (я думаю), SVN имеют проблемы с этим. Это, вероятно, означает, что я - тот с проблемами - зависания для потерянного прошлого. Но я оцениваю то, что должно предложить прошлое. (Я могу выйти сухим из воды, потому что большая часть моего кода не переходится. Я не уверен, сколько сделало бы ветвление различия.)

Как использовать мерзавца сверху ClearCase!

• Мерзавец за кулисами, под покрытиями и на вниз низком
• ClearCase глобально, мерзавец локально
• Clearcase для мерзавца, мост мерзавца-cc

Я работал в ряде средних и крупных проектов успешно с помощью и Clearcase и SVN. Оба - большие инструменты, но команда, использующая их потребность, зарегистрировала процессы. Создайте процесс, который описывает, как Вы будете использовать систему управления версиями.

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

В основном решите, идете ли Вы в 'всегда, ответвление' или 'никогда не переходит'.

Никогда не переходите схема:

• Никогда схема ответвления не то, что использует SourceSafe, где файлы заблокированы во время контроля и становятся доступными во время регистрации. Эта схема и является хорошо для маленького (1 или 2 разработчика) проектами команды.

Всегда схема ответвления:

• Всегда схема ответвления означает, что разработчики создают ответвления для каждого bugfix, или функция добавляют. Эта схема необходима для больших проектов, проектов, которые имеют вывод (buildmeister), кто управляет тем, какие изменения позволяются в/main/LATEST в Clearcase или соединительную линию / в SVN.
• Всегда схема ответвления означает, что Вы часто можете регистрация w/o страх перед повреждением сборки. Ваша единственная возможность повредить сборку только после Вашего bugfix или функции завершено, и Вы объединяете его с/main/LATEST.

'Ответвление при необходимости' является компромиссом и может работать лучше всего на многие проекты.

2) С Clearcase (и Подверсия) необходимо учиться объединяться - слияние является другом. Учитесь использовать объединяющиеся возможности Clearcase или использовать инструмент как Вне всякого сравнения или emacs-различный. Если Ваш проект будет хорошо построен из модулей (много маленьких отделенных файлов), то Вы принесете пользу с меньше (или не) конфликтам во время слияния.

3) Наслаждаться.