Звездная команда (Часть 5). Объекты и элементы.

Темой данной статьи является на первый взгляд несколько запутанная архитектура отображения объектов Starteam в представления по средствам ассоциативных элементов. Понимание данной темы не всегда доступно с первого раза. Более того, эти нюансы нужны исключительно для тонкой настройки работы Starteam и редко используются в обычной практике. Поэтому, если вы только знакомитесь со Starteam, возможно, эта статья будет для вас лишней. =)

Важно понять, как объекты отображаются с помощью представлений (видов). Каждый объект отображается в некоторый вид с помощью дополнительной сущности, называемой элементом (Item) или, как ещё говорят, членом представления. Когда новый объект, допустим файл, добавляется к представлению, Starteam создает новый объект типа файл с версией 1.0, и это влечет за собой создание нового элемента, который "указывает" на тот файл. Элемент не только определяет, на какой файл ссылаются, но и определяет папку, в которой появится файл. Так, например, если Вы перемещаете файл из одной папки в другую, Вы фактически изменяете элемент - файл, чтобы указать на другой родительский элемент - папку, но сами объекты файл и папка фактически не измененяются. Отношения между элементами и объектами иллюстрированы на следующем рисунке.

В этом примере изображены два представления, указывающих на элемент - корневую папку. Каждый элемент указывает на соответствующий объект, и каждый элемент, отличный от элемента-коренвой папки указывает на родительский элемент-папку, определя тем самым, где располагается этот элемент.
Элемент, созданный от имени нового объекта называют родительским элементом. Дочерний элемент, созданный копированием родительского или дочернего элемента, позволяет отобразить тот же самый объект в другом месте. Дочерний элемент указывает на родительский элемент, с которого он был скопирован. Дочерние элементы создаются в двух случаях:
1) Когда используются дочерние представления(child views): В случае, когда новое представление создано как потомок другого представления, элементы родительского представления копируются, чтобы создать элементы дочернего представления. Сами объекты при этом не копируются – новые дочерние элементы представления просто указывают на те же самые объекты.
2) Когда используются разделяемые ресурсы (Shares): Элемент может быть явно скопирован, создавая "разделяемый" элемент (надо держать Ctrl и тянуть мышкой нужный элемент в StarTeam клиенте). В этом случае, выбранный элемент будет скопирован и будет указывать на тот же самый объект, что и оригинальный элемент.

Основное различие между дочерними представлениями и дочерними разделяемыми элементами - их начальная конфигурация. На поведение объекта частично влияет конфигурация родительского или дочернего элемента, по средствам которого мы имеем возможность управлять этим объектом. Чтобы понимать, как ведут себя родительские и дочерние элементы, необходимо понять разницу между свойствами элемента и свойствами объекта.
Свойства объекта: Большинство свойств, которые Вы видите – имя, кем изменен, версия, данные (для файла), и т.д. – принадлежит объекту. Когда любое из свойств объекта изменяется – создается другая ревизия объекта. Например, если текущая ревизия Запроса об изменении - 1.2, и свойство «Ответственный» изменено, модифицированный объект типа «Запрос об изменении» будет сохранен с ревизией 1.3. Если в новой версии файла текущая ревизия 1.4.1.2, то следующая будет соответственно - 1.4.1.3.

Свойства элемента: Элемент обладает свойствами, которые определяют, на какой объект этот элемент ссылается, папку, в которой он должен отображаться, и как должны обрабатываться изменения объекта через элемент. Большинство свойств элемента, например, родительское представление и родительская папка управляется StarTeam неявно на основании действий клиента. Однако, существует три ключевых свойства элемента, которые непосредственно затрагивают свойства объекта, на который ссылается элемент:
1) Код объекта (Object ID): Это свойство определяет ветвь объекта, на которую ссылается элемент. Каждый новый объект получает уникальный Код объекта, и его номер ревизии начинается с 1.0. Номер ревизии объекта увеличивается каждый раз, когда обновляется состояние объекта (1.1, 1.2, и т.д.), но код объекта при этом остается неизменным. Следовательно, код объекта, на который ссылается элемент, указывает на целую ветвь объекта и возможно на конкретную ревизию. Когда же объект ветвится, создается новый объект с новым кодом объекта, и номер его ревизии расширяется, чтобы отразить точку ответвления (например, 1.2.1.0). Элемент ссылается на новую ветвь, обновляя код объекта, на который он указывает.
2) Конфигурация поведения элемента (Behavior Configuration): Это свойство определяет, является ли элемент «плавающим» или привязан к определенному моменту времени. Когда поведение элемента определено, как плавающее, элемент указывает на последнюю ревизию ветви объекта, на который ссылается этот элемент. Когда поведение привязано к конкретному моменту времени, элемент ссылаестся на ревизию объекта, которая был актуальным на то время.
3) Автоматическое ветвление при изменении (Branch-on-change): Это свойство действительно только для дочернего элемента, ссылающегося на файл или «запрос на изменение». Оно определяет, что случается при изменении объекта через элемент. Если это свойство установлено в True, Starteam при любой модификации заставляет начинать новую ветвь объекта. Например, если файл загружается в БД (check in) через элемент, и текущая ревизия равна 1.2, автоматически создается новая ветка 1.2.1.0. Когда это свойство установлено в False – это означает, что, или основной объект уже ветвился через этот элемент, или изменение через элемент оперирует тем же самым объектом что и родительский элемент, или этот элемент только для чтения (заморожен).

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

(продолжение следует...)

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

Звездная команда (Часть 4). Понимание представлений.

Сегодня я подробнее расскажу о представлениях (View), которые реализованы в Starteam. Но прежде я хотел бы сделать несколько замечаний про терминологию, которая используется в статье. Во многих системах контроля версий для обозначения копии файла, полученного в результате изменения оригинала используется слово "Версия" (Version). Собственно, отсюда и возникло название таких систем. И Starteam в этом случае не исключение, только версии файла в Starteam называются Revision (что тоже, в общем-то, интуитивно понятно). Кроме простой версионности в Starteam реализовано так называемое ветвление (Branching), которое позволяет рассматривать версии файлов в рамках некого дерева изменений, имея несколько актуальных версий изменяемого элемента (файла, требования и т.п.) на разных ветках этого дерева. Поэтому полный номер версии элемента определяется атрибутом Branch revision, который представляет собой композицию номеров версий файла и ветки. Т.о. когда в статье идет речь про ветвление, то это автоматически подразумевает и версионность элемента.

Когда Вы создаете проект, Вы также создаете начальное или корневое представление этого проекта. В процессе работы над проектом также может быть создано несколько представлений дополнительно. Зачем они нужны? Представления позволяют реализовать очень важную функциональность сервера Starteam – отображать только определенные элементы, входящие в его состав. Причем, критерием отбора могут являтся не только обычные атрибуты элемента, вроде имени и типа, но и дата создания и изменения, версия элемента и т.д. Другими словами, Вы можете конфигурировать представление так, чтобы показать элементы, существовавшие раньше или позже определенного события, на конкретный момент времени, базирующиеся на специальной метке или находящиеся в некотором состоянии. В зависимости от своего назначения можно классифицировать представления по нескольким типам:

1) Представления, динамически отображающие изменения исходного кода и документов в вашем проекте (Dynamic view). Заданное по умолчанию корневое представление относится как раз к этой категории. Оно позволяет вам видеть все файлы и другие элементы проекта «как есть» на текущий момент времени. Представление этого типа отображается, когда Вы выбираете в меню View > Select Configuration > Current Configuration.
2) Изменяемое представление – ссылка (Reference view). Под ссылкой в данном случае следует понимать ссылку на подмножество элементов, найденных в первоначальном представлении. Такое представление часто содержит только элементы, представляющие интерес для определенной группы разработчиков. Любое изменение, сделанное в представлении этого типа изменяет тот же самый элемент в первоначальном представлении. Это происходит потому, что представление содержит ссылки к элементам в первоначальном представлении и не ветвится (см. ниже), когда происходят изменения.
3) Неизменяемое представление-ссылка (RO reference view). Оно основано на определенном состоянии первоначального представления. Такое представление-ссылка создается обычно для удобства поиска конкретных ревизий элементов, используемых в определенных релизах программы. Оно может быть "плавающим" или жестко привязан к определенной дате. Представления этого типа используются в основном для того, чтобы можно было легко восстановить старые версии программы.
4) Представления, разрешающее выполнять ветвление элементов (Branch all view. Также часто их называют версионными). Ветвящиеся представления можно использовать, чтобы изменить элементы, найденные в определенном представлении, не затрагивая эти элементы в других представлениях. Таким образом, мы можем создать несколько ветвящихся представлений в одном проекте и работать над разными версиями программы параллельно, не вызывая конфликтов. Поэтому, ветвящееся представление должно использовать рабочую папку, отличную от рабочей папки ее родительского представления. Использование той же самой рабочей папки для обеих представлений не только запутывает, но и может создать серьезные проблемы. Например, изменения в файлах одного представления могут быть затерты, когда Вы выгружаете файлы из БД от другого представления. Эта происходит потому, что два этих файла имеют одинаковые названия и рабочую папку. Или же состояние файла на клиенте может быть определено неправильно и ввести пользователя в заблуждение. Например, StarTeam может сообщить о состоянии файла в одном представлении как "Неизвестное", "Устаревшее" и т.д., когда действительное состояние файла "Отсутствует", и файл от другого представления с тем же самым названием находится в рабочей папке. Следует отметить, что благодаря своим своствам ветвящиеся представляния - самые востребованные производные представления в Starteam. Обычно, разработчики используют исключительно их.
5) Неветвящееся представление (Branch None view). Этот тип представления, как и ветвящееся представление, основывается на некотором родительском представлении. Как следует из его названия – элементы данного представления не ветвятся при их изменении.
6) Непроизводное представление (Non-derived view). Это самостоятельное представление, которое не наследуется от какого-либо другого представления. Соответственно, оно по умолчанию создается пустым и все элементы в него добавляются по желанию пользователя.

Теперь давайте подробнее рассмотрим наиболее интересные и полезные ветвящиеся представления. Ветвящееся представление - представление, которое разрешает папкам, и другим элементам в представлении отделиться от соответствующих элементов в родителе и, начиная с этого момента, стать изменяемой копией родителя. Ветвление применяется только к папкам, файлам, и запросам на изменение. При этом можно настроить представление так, чтобы определенные его элементы не ветвились. Требования, задачи и обсуждения не ветвятся никогда. Изменения таких элементов можно осуществить в представлении, в котором они были созданы, в представлении, в которое они были перемещены или расшарены, или в "плавающем" дочернем представлении, предназначенном только для чтения. Новые ревизии таких элементов могут быть рассмотрены в любом "плавающем" дочернем представлении.
Пока элемент не ветвится, соответствующие элементы в обоих представлениях остаются идентичными. После того, как пользователь изменил элемент, появляется новая ветвь или, как ещё говорят, версия этого элемента, и они больше не являются идентичными. При этом номер ревизии элемента указывает на новую ветвь. Единственный способ снова сделать элементы идентичными состоит в том, чтобы вручную объединить их, сравнивая и объединяя представления с помощью команды Compare/merge views. После того, как происходит ветвление, StarTeam больше не посылает и не применяет обновления от соответствующего элемента в родительском представлении. Из соображений безопасности, удаления, сделанные в родительском представлении не размножаются к дочернему представлению и наоборот. Если Вы хотите удалить папку или элемент изо всех связанных представлений, Вы должны удалить их из каждого представления в отдельности.
Ветвящиеся представления предназначены для различных целей:
1) Выполнение разнообразных потребностей в зависимости от ваших задач. Например, можно создать исправленную версию или заказную версию вашей программы, ответвленную от предшествующего коммерческого релиза.
2) Начало разработки следующего релиза вашей программы, используя некоторые или все файлы от предыдущего выпуска.

3) Хранение части вашего проекта приватно, пока она полностью не закончена и не протестирована. Когда потребуется, Вы можете объединить ваши изменения с основным проектом.

(продолжение следует)

Звездная команда (Часть 3). Логическая конфигурация проекта

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

Итак:
1) Каждый Starteam сервер может содержать несколько проектов:
2) Каждый проект имеет главное представление (View) и любое количество дочерних представлений: 3) Каждое представление (и главное, и дочерние) ассоциировано с некоторой StarTeam-папкой, называемой главной (root folder): 4) Каждая главная StarTeam-папка может содержать иерархию дочерних папок, называемых StarTeam-каталогом (иерархией папок):
5) Когда администратор создает новый проект, автоматически создаются главный вид и главная папка проекта. Они будут иметь такое же имя, как и имя проекта, например «GreatApp» (позднее администратор может поменять эти названия): Рассмотрим пример, показанный на следующем рисунке.

В нем конфигурация сервера содержит два проекта: Dev1, чье главное представление имеет 2 дочерних представления, и Doc1, главное представление которого имеет единственное дочернее представление, которое в свою очередь тоже имеет дочернее представление. Как видно из рисунка, развитие проектов сохранено в консолидированном репозитарии – базе данных и файловом архиве. В любое время пользователь Starteam может выбрать нужное ему представление и начать с ним работу. Однако, чтобы понять все нюансы работы с представлениями, следует подробнее разобраться, что же представляет собой это представление. Об этом мы поговорим очень скоро, как только я сформулирую свои мысли в виде буквенно-цифровых последовательностей, называемых в простонародии текстом.

(продолжение следует...)

Продалися =)

То, о чем так долго говорили большевики, свершилось! А я уж, грешным делом, думал, что идея продавать софтверный бизнес оставила Borland. Многочисленные блоги пестрят сообщениями о том, как это круто. Наверное, так оно и есть. Ценник, правда, сбили на 70 мультов. Но, видимо, для Borland и это хорошо. То, что мирового лидера с многолетней историей в области разработки языков программирования, компиляторов и IDE покупает фирма, делающая утилитки для баз данных о чем - то да говорит. Воистину, мир меняется... и мы вместе с ним.

Ну, как говорится, на новом месте - приснись жених невесте =) Пожелаем удачи CodeGear в новой итерации.

Звездная команда (Часть 2). Объекты Starteam

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

1. Файлы(Files): Как во всех SCM системах, файлы - самый важный тип объекта в StarTeam. Свойства файла содержат метаданные, такие как атрибуты безопасности, история изменения, ссылка на лицо, изменившее файл и т.д. Понятно, что файлы и сами по себе содержат двоичные или текстовые данные и сохраняются в хранилище(Vault) на сервере. Файлы являются версионными и могут ветвиться в отдельные версионные деревья. Файлы поддерживают и возможность создания связей(линков) и прикрепления меток.



2. Запросы об изменении(Change Requests): StarTeam поддерживает систему отслеживания ошибок и изменений с помощью объектов типа Change Requests. Подобно файлам, CR может быть версионной, связанной, помеченной метками, ветвиться и т.д. CR обычно используется, чтобы представить дискретные запросы типа сообщений об ошибке, некорректной, неправильной работе программы, а также для внесения изменений в её работу.


3. Задачи(Tasks): В StarTeam задачи похожи на этапы планирования работы, используемые в системах руководства проектоми типа Microsoft ® Project (Фактически, задачи StarTeam могут быть синхронизированы с задачами Microsoft Project). Задача обычно представляет один конкретный шаг в решении комплексного задания и может быть назначена нескольким сотрудникам. Задача может быть разделена на подзадачи и отслежена через лог записей о её выполнении. Задачи также являются версионными и могут быть промаркированы, связаны, и т.д, однако они не могут ветвиться в версионные деревья подобно файлам и запросам об изменени.


4. Темы(Topic): тема - подобие сообщения в телеконференции, которое может быть послано одним пользователем, ответ написан другим и т.д. Цепь сообщений на данную тему создает “дерево обсуждений”, которое может быть присоединено к файлу, запросу об изменении, или другому объекту. Подобно задачам, темы являются версионными, но не не могут ветвиться в версионные деревья.


5. Требования(Requirements): StarTeam поддерживает упрощенную систему требований, которая может быть использована для документирования на ранних стадиях разработки жизненного цикла проекта. Требования могут быть созданы и реализованы непосредственно в StarTeam, или они могут быть импортированы и синхронизированы с объектами от других систем управления требованиями типа CaliberRM ™. Требования являются версионными, но не не могут ветвиться в версионные деревья.


6. Папки(Folders): Каждое представление(вид) имеет корневую(главную) папку, которая обычно содержит дерево подпапок. Папка может содержать объекты любого типа, включая другие папки. Хотя папки – это по сути дела "контейнеры", они имеют свойства и являются версионными. Следовательно они также являются объектами StarTeam, и, подобно файлам и запросам об изменении, могут ветвиться в версионные деревья. Обратите внимание, что логический путь папки определяется на основании пути его родительских папок. Однако, путь к соответствующей рабочей директории, в котором сохранены файлы на клиенте, может не соответствовать логическому пути. Т.о. рабочая директория может быть переопределена на клиенте. Это очень удобно, так как у разных разработчиков системы настроены по разному. Более того, могут использоваться разные ОС, например Windows и Linux.

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