• Создание и использование закладок (bookmarks)
• Операция Pull (Check-Out)
• Работа с историей версий проекта (History)
• Подсистема оповещения об изменениях в проекте;
• Несколько практических советов;
• Как не следует настраивать и эксплуатировать TeamSource.
• Как следует настраивать и эксплуатировать TeamSource.
• Заключение

Создание и использование закладок (bookmarks)

Закладки предназначены для пометки текущей версии (см. раздел "Версии проекта и отдельных его составляющих" на странице ) проекта таким образом, чтобы затем использовать эту пометку для выполнения например процедуры Pull.

Поскольку при установке закладки помечаются все файлы, входящие в проект, Вы можете установить закладку после выполнения операции Check-In для окончательных версий файлов для какого-либо ключевого состояния проекта (например для бета-версии). Удостоверившись, что все файлы текущей версии могут быть использованы для сборки проекта, Вы устанавливаете закладку с соответствующим комментарием. За счет этого даже при внесении последующих изменений Вы будете обладать возможностью собрать версию проекта, составляющие которой помечены закладкой. Для этого необходимо сначала выполнить операцию Pull в отдельный каталог, выбрав предварительно необходимую закладку из списка, выводимого TeamSource (Рисунок 42), а затем выполнить сборку проекта, используя исходные тексты из соответствующего каталога.

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

Для управления закладками в TeamSource используется специальный диалог, открывающийся через меню Project | Bookmarks... .

Рисунок 40. Диалог управления закладками в проекте.

При создании закладки (кнопка "Add") выводится диалог "Bookmark Properties".

Рисунок 41. Диалог создания закладки.

Закладка может быть локальной (Local) или глобальной (Global). Глобальные закладки будут видны и могут быть использованы всеми участниками проекта, тогда как локальные видны и используются только создавшим их пользователем. Создавать глобальные закладки имеют право только пользователи с признаком Administrator (см. "Изменение параметров существующего проекта" на странице *).

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

Рисунок 42. Диалог выбора закладки для выполнения операции Pull.

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

В том случае, если в списке Bookmark выбран первый пункт (None (current state)), TeamSource создаст локальную копию последних версий файлов проекта.

Операция Pull выполняется начиная с корневого каталога, указанного в поле "Local directory" в верхней части окна Remote.

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

Работа с историей версий проекта (History)

При переходе в режим History интерфейс TeamSource принимает следующий вид:

Рисунок 43. TeamSource в режиме "History".

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

Подсистема оповещения об изменениях в проекте

Подсистема оповещения или Publishing System продукта TeamSource тесно интегрирована с другими частями хост-приложения. За счет сведения к разумному минимуму настроек этой подсистемы становится возможным быстро и без особых проблем настроить оповещение участников проекта об изменениях в хранилище версий.

К тому же, за счет использования для рассылки протокола SMTP (Simple Mail Transfer Protocol) Вы можете использовать для оповещения стандартный внутрифирменный сервер сообщений (практически все современные операционные системы серверного класса поддерживают этот протокол и соответствующие службы) и даже использовать почтовый сервер вашего Internet-провайдера для рассылки оповещений разработчикам, работающим вне офиса, в другом городе и даже на другой стороне земного шара.

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

Так, пользователи из списка "Publish Summaries To:" будут получать только сводные отчеты об операциях с хранилищем версий, не содержащие технической информации, а только с комментариями к операции Check-In, именем пользователя, выполнявшего операцию и датой ее проведения.

Пользователи из списка "Publish Logs To:" будут получать журналы выполнения операций Check-In и других действий со всей технической информацией.

Пользователи из списка "Publish File Changes To:" будут получать сводные отчеты, содержащие информацию о том, какие файлы были добавлены или удалены из проекта.

Рисунок 44. Настройка подсистемы оповещения.

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

Несколько практических советов

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

1. Не используйте для хранения удаленной копии проекта компьютер, загруженный какими-либо ответственными задачами, либо создающими большую загрузку задачами, например, сервер баз данных. Это может привести как замедлению выполнения основной нагрузки, так и к замедлению работы с хранилищем версий.
2. Не оставляйте включенным флаг "Enable Mirror Directory" (см. раздел "Изменение параметров существующего проекта" на странице ) перед закрытием проекта в том случае, если имеется вероятность того, что путь, указанный в параметре "Mirror Directory" может оказаться недоступным, например, если Вы создали этот каталог на съемном носителе и извлекли его из привода. При открытии проекта и недоступности этого пути TeamSource выдаст сообщение об ошибке и не откроет проект до тех пор, пока путь не будет создан заново или устройство не будет приведено в готовность.
3. Не создавайте хранилище версий проекта прямо в корневом каталоге дискового раздела. Создайте каталог, общий, например, для рабочей группы, на который можно будет заодно наложить соответствующие права доступа, а уже в нем расположите корневой каталог удаленной копии проекта.
4. Не используйте для хранилища версий проекта раздел жесткого диска, на котором могут создаваться временные файлы операционной системы, динамические файлы подкачки и д.п. При сбое в операционной системе или каком-либо приложении, особенно на машине, выполняющей функции сервера каких-либо задач помимо хранения файлов, возможность потери хранилища версий в такой ситуации значительно возрастает.
5. Не пренебрегайте читаемостью названий имен проектов, комментариев к блокировкам и т.п. Зачастую неверно истолкованное название или комментарий может создать больше проблем, чем полный "обвал" компьютерной сети или сбой жесткого диска с хранилищем версий проекта.
6. Не раздавайте всем участникам проекта признак Administrator – ничего кроме проблем с блокировками это не принесет.
7. При создании проекта TeamSource по программному проекту, достаточно давно находящемуся в разработке, не включайте признак "Require File Comments" (Рисунок 19. Изменение параметров проекта. Закладка "General": общие параметры.) при первичном наполнении хранилища версий. Если в проекте уже имеется не одна сотня файлов, даже нажать на кнопку "OK" сотню-другую раз во время выполнения цикла Check-In будет достаточно утомительно. Комментарии можно будет ввести позже прямо в хранилище версий.

1. Выделите для хранилища версий отдельный дисковый раздел на доступной через компьютерную сеть машине. Лучше если это будет выделенный файловый сервер, например на базе Novell Netware с включенной поддержкой длинных имен или Windows NT с дисками, отформатированными в NTFS. Создайте отдельные каталоги для разных рабочих групп, а уже в них создавайте хранилища версий. На такую структуру легко наложить права доступа для отдельных пользователей, например защитить от стирания корневые каталоги хранилищ версий.
2. Производите циклическое резервное копирование хранилища версий либо его "зеркальной" копии на специальное устройство массового хранения (стример, магнитооптику, CD-RW и т.п.) не менее чем раз в сутки.
3. Поскольку архивы версий имеют тенденцию со временем разрастаться, после очередного резервного копирования, например раз в месяц, имеет смысл удалять ненужные версии файлов из архивов.
4. Расставляйте закладки на все значимые версии проекта, снабжая их содержательными комментариями. Впоследствии это может сэкономить массу времени при отладке или поиске необходимой версии.
5. Включите признак "Require File Comments" (Рисунок 19. Изменение параметров проекта. Закладка "General": общие параметры.) после первичного наполнения хранилища версий или при создании проекта TeamSource параллельно новому программному проекту. Одна-две фразы содержательного комментария для одного-двух файлов за операцию Check-In с одной стороны не займут много времени разработчика, а с другой стороны — помогут ему же разобраться с тем, что именно было изменено или добавлено в -1871 версии файла по исчислению проекта и два-три года назад по реальному времени.
6. Включайте в проекты TeamSource помимо собственно файлов проекта и файлы документации по этому проекту, например сопроводительную документацию к версиям продукта. Это опять-таки поможет сэкономить время при сборке конечной версии.
7. И наконец, ВНИМАТЕЛЬНО читайте сообщения TeamSource, особенно при выполнении различных необратимых действий на фоне длительного отсутствия резервного копирования хранилища версий (см. также пункт b).

Заключение

Итак, мы рассмотрели устройство и приемы работы системы контроля (управления) версий программных проектов TeamSource. За простым, незамысловатым интерфейсом этого программного продукта скрывается совсем не простое внутренне устройство, созданное разработчиками для разработчиков и потому достаточно действенное, чтобы покрыть 90 (если не более) процентов потребностей большинства как одиночных разработчиков программного обеспечения, так и групп программистов. Поэтому не следует смущаться отсутствием различных красивостей и непомерных объемов исполняемых файлов, ведь все гениальное — просто!

К тому же, Вы имеете прекрасную возможность внести собственный вклад в развитие этого перспективного продукта, так необходимого пользователям средств разработки Inprise/Borland (и не только!). Берите на вооружение API расширений TeamSource и Borland Delphi (или C++ Builder) и создавайте свои собственные, сложные (или простые) средства, облегчающие вашу работу.

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

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме Inprise/Borland