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

Question

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

Answer 1

Основные понятия?

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

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

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

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

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

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

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

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

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

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

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

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

• путь доступа: чтобы получить доступ к определенной версии файла / каталога, вам нужно знать его расширенный путь (состоящий из веток и версий). Это называется "расширенный путь": myFile@@/main/subBranch/Version,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Использование CC не тривиально, хотя в настоящий момент я считаю "мерзавец" таким же пугающим, как и 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, занимаясь отдельными наборами продуктов по одному.

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

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

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

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

Если вы попытаетесь выполнить трехстороннее объединение редактируемых версий файлов SCCS (с нотацией%x%), то в строках, содержащих метаданные, не возникнет конфликтов, если вы не изменили метаданные в этих строках (например, путем изменения из US- стиль%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 не согласны) состоит в том, что в ней отсутствует система для обработки ключевых слов, и, следовательно, также отсутствует соответствующий менеджер слияния.

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

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

Недостатком этого является то, что он требует либо специального инструмента различий, который распознает маркеры метаданных и обрабатывает их специально, либо он требует, чтобы файлы, подаваемые в инструмент разностей, были канонизированы (маркеры метаданных сведены к нейтральной форме - $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) все еще несколько спекулятивен; Я еще окончательно не решил, оставить ли их. Они также являются внутренними для реализации и не влияют на внешний интерфейс, поэтому мне пока не нужно принимать решение. Я не уверен, как справиться с этим с помощью мерзавца. Я не хочу встраивать библиотечный код в библиотеку, которая должна быть установлена ​​до того, как вы сможете собрать мое программное обеспечение - это слишком обременительно для моих клиентов. Таким образом, каждая программа будет по-прежнему распространяться с копией кода библиотеки (разного рода обременительно), но только с кодом библиотеки, который необходим программе, а не со всей библиотекой. И я выбираю для каждой программы, какие функции библиотеки используются. Таким образом, я бы не экспортировал целое поддерево; действительно, коммит, который охватывал последние изменения в коде библиотеки, как правило, совершенно не связан с коммитом, который охватывал последние изменения в программе. Я даже не уверен, должен ли git использовать один репозиторий для библиотеки, а другой для программ, которые ее используют, или общий большой репозиторий. И я не буду мигрировать на мерзавца, пока не пойму это.

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

Answer 4

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

Answer 5

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

• Git Backstage, под обложками и внизу
• ClearCase глобально, Git локально
• Ящик для Git, git-cc bridge

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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

В основном решите, будете ли вы "всегда ветвиться" или "никогда не ветвиться".

Схема никогда не ветвится:

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

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

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

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

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

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

Answer 11

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

Answer 12

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

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

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