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

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

Ответы

Ответ 1

Основные концепции

  • централизованный (-реплицированный) VCS: ClearCase находится на полпути между централизованным миром VCS (одним или несколькими "централизованными" репозиториями или базовыми объектами VOBS - каждый разработчик должен получить доступ к фиксации) и распределенный мир VCS.
    Но он также поддерживает "реплицированный" режим, позволяющий реплицировать репо на удаленном сайте (MultiSite ClearCase), отправлять дельтам и управлять собственностью. (лицензионные сборы при этом довольно крутые, хотя)
    Это не настоящая "децентрализованная" модель, поскольку она не допускает параллельных параллельных эволюций: ветки освоены в одном VOB или другом; вы можете только зарегистрировать главный VOB для ветвей, освоенных там, хотя у вас есть только доступ к любой ветке на любой реплике.

  • хранилище линейных версий: каждый файл и каталог имеют линейную историю; между ними нет прямых отношений, таких как DAG VCS (Directed Acyclic Graph), где история файла связана с одной из связанных с каталогом к фиксации.
    Это означает

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

    • Это также означает, что merge должен найти общий базовый вкладчик (не всегда такой же, как обычный предок), через исследование истории (см. следующий пункт).

      (Git находится на противоположном конце этого спектра, будучи как децентрализованными, так и DAG-ориентированными:

      • если node его графа имеет тот же "id", что и node другого коммита, он не нуждается в дальнейшем изучении: все субграфы гарантированно будут идентичны
      • объединение двух ветвей на самом деле является слиянием содержимого двух узлов в DAG: рекурсивным и очень быстрым для нахождения общего предка)

alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif

  • 3-way merging: чтобы объединить две версии, ClearCase должна найти общего основателя в своей линейной истории, которая может быть довольно длинный для сложного дерева версий (ветвь/суб-ветвь/суб-суб/ветвь,...) и базовый ClearCase merge объединяет файл или каталог, но не рекурсивный. Это касается только одного файла или одного каталога без его файлов (ct findmerge является рекурсивным)

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

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

(Создайте два файла с одинаковым размером и содержимым, они получат одинаковый идентификатор в Git - SHA1-ключ - и будут сохраняться только один раз в репозитории Git! Не так в ClearCase. < ш > Кроме того, если два файла с одним и тем же путем и именем создаются в двух разных ветвях, их идентификатор отличается друг от друга, эти два файла никогда не будут объединены: их называют "злыми близнецами" )

  • ветки являются первоклассными гражданами: большинство VCS рассматривают ветку и тег как одно и то же: одна точка в истории, из которой может развиваться новая линейная история (ветвь) или от того, где прикреплено описание (тег).
    Не так для ClearCase, где ветка - это способ ссылки на номер версии. Любой номер версии начинается с 0 (только с ссылкой в ​​ClearCase) до 1, 2, 3 и т.д. Каждая ветвь может содержать новый список номеров версий (0, 1, 2, 3).
    Это отличается от других систем, где номер версии уникален и всегда растет (например, ревизии в SVN) или просто уникален (например, клавиши SHA1 в Git).

  • доступ к контенту: для доступа к определенной версии файла/каталога вам необходимо знать его расширенный путь (состоящий из ветвей и версий). Он называется "расширенным именем пути": [email protected]@/main/subBranch/Version.

(Git ссылается на все через id-SHA1-based -: version [или commit], дерево [или версию каталога] и blob [или версию файла, или, скорее, содержимое файл]. Таким образом, это "id-accessed" или "id-referenced".
Для ClearCase идентификатор ссылается на "элемент": каталог или файл, независимо от его версии.)

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

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

  • плоское хранилище: VOB хранятся в проприетарном формате с простыми файлами. Это не база данных с легким языком запросов.

  • доступ к локальной или сетевой рабочей области:

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

  • централизованное депортированное хранилище: [view] хранилище для хранения некоторых данных и предотвращения некоторых или любых сообщений с центральной ссылкой.
    рабочее пространство может иметь:

    • разбросанное хранилище: как и подкаталоги .svn по всему месту
    • централизованное хранилище: как и хранилище представлений в ClearCase, они содержат информацию о файлах, отображаемых в представлении, и это хранилище уникально для представления.
    • депортированное хранилище: хранилище не является частью самого представления/рабочей области, но может быть расположено в другом месте на компьютере или даже снаружи в LAN/WAN

(Git не имеет "хранилища" как такового. Его .git - это фактически весь репозиторий!)

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

(это означает, что механизм на самом деле слабее, чем система свойств SVN, где свойства могут иметь историю; Git на другом конце не слишком увлекается метаданными)

  • системная защита: владелец и права, связанные с файлом/каталогом или репозиториями, основаны на управлении правами базовой системы. В ClearCase нет прикладной учетной записи, и группа пользователей напрямую основана на существующей группе Windows или Unix (что довольно сложно в гетерогенной среде с клиентами Windows и сервером Unix VOB!)

(SVN больше похожа на "серверную" защиту, где сервер Apache может получить первый уровень защиты, но должен быть завершен с помощью крючков, чтобы иметь более тонкий цвет прав.
Git не имеет прямого управления правами и должен управляться с помощью перехватов во время push или pull между репозиториями)

  • Доступные крючки: любое действие ClearCase может быть целью крюка, называемого триггером. Это может быть операция pre или post.

  • Управляемый CLI: cleartool - это интерфейс командной строки, из которого можно выполнить все действия.

Ответ 2

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

  • Всегда оставляйте хорошие комментарии при регистрации.
  • Используйте общую конфигурационную спецификацию и не меняйте ее очень часто.
  • Никогда не пытайтесь использовать CC через VPN или медленное сетевое подключение.
  • При запуске выключите загрузку с CC-врача.
  • Не перемещайте файлы в разные каталоги.
  • Расписание не менее 2 минут на файл для проверки.
  • Представления снимков медленны, но динамические представления медленнее.
  • Сделайте привычку разработки для проверки в раннем и часто, потому что зарезервированные файлы и слияния являются болезненными.
  • Попросите всех разработчиков проверить файлы по умолчанию без ограничений.

Ответ 3

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

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

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

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

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

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

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

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

Я написал:

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

В ответ @VonC отмечает:

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

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

Фон

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

Эксперимент Early ClearCase с триггерами - и слияние ад

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

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

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

Если вы попытались с трехсторонним слиянием редактируемых версий файлов SCCS (с обозначением% x%), тогда не было бы конфликтов в строках, содержащих метаданные, если вы не изменили метаданные на этих строках (например, путем изменения от US-style% D% датируется в британском стиле% E% дат - SCCS не поддерживает стандарты ISO-стиля 2009-03-15 в качестве стандарта.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

Eric Source Control HOWTO - отличное руководство, независимое от инструмента.

Ответ 5

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

В принципе решайте, собираетесь ли вы "всегда ветвь" или "никогда не ветвь".

Никогда не работает:

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

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

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

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

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

3) Наслаждайтесь.

Ответ 10

Если вы используете ClearCase, убедитесь, что вы используете UCM, который поставляется вместе с ним и Composite Components.

Это делает все ваше разветвление/слияние без усилий. Я говорю о крупных ветких реорганизации, которые работают в течение 6 месяцев с участием десятков тысяч изменений, включая переименование каталогов, переименование файлов и т.д., Которые автоматически разрешают 99,9% дельт.

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

Единственная проблема, с которой я сталкиваюсь в UCM, заключается в том, что история не может охватывать компоненты. Если вы разбиваете компонент на несколько новых компонентов, каждый новый компонент запускается с/main/0.

Ответ 11

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

Ответ 12

Существует очень удобная команда cleardescribe, которая полезна много раз. Может использоваться для получения информации о ярлыках и ветках. Синтаксис:

cleardescribe lbtype:<LABELNAME>@\<VOB-NAME>
cleardescribe brtype:<BRANCHNAME>@\<VOB-NAME>

В частности, это позволяет вам знать, что метка была применена в какой ветке и какая ветка является родительской ветвью к ответвлению.