Методика организации командной работы над Flash-проектом

Использование subst и hardlink'ов

subst - исключительно полезная утилита для создания виртуальных дисков, которые, как уже упоминалось, очень удобно использовать в качестве места размещения файлов-источников для author time sharing. Альтернативой команде subst является функция Map Network Drive, доступная из Windows Explorer.

Синтаксис:

• subst <drive>: <directory> для создания виртуального диска;
• subst <drive>: /d для удаления виртуального диска. При выполнении этой команды убедитесь, что текущая директория не лежит на виртуальном диске.

Жесткие ссылки ( hard links ) - функция файловых систем UNIX, в Windows появилась начиная с версии 2000. Вы можете сделать несколько ссылок на один файл из разных каталогов, причем все они будут равноправны. Иными словами, на файл всегда существует минимум одна жесткая ссылка. Если последняя ссылка на файл удаляется, файл уничтожается. Как это можно использовать? Представьте, что у вас есть библиотека, которой пользуются много разработчиков, и у каждого из них в разных рабочих директориях лежат разные флэш-ролики, использующие одну runtime-shared библиотеку, размещенную в подкаталоге library. Вы можете организовать автоматическое обновление символов в библиотеках. fla-файлов с помощью author time sharing с виртуального или сетевого диска. Но вы не можете с помощью виртуального диска подменить подкаталог library или файлы, лежащие в нем. Вот для этого как раз и служат жесткие ссылки: эти файлы можно залинковать на сетевой диск, и они будут обновляться автоматически.

Есть программы, которые позволяют это делать, например, Far 1.5 ( Alt-F6 ). Обязательное условие: все ссылки должны лежать в одном томе NTFS, то есть дизайнеры флэш-роликов не могут держать свои каталоги для разработки на локальных дисках.

Способы применения системы контроля версий

Обычно системы контроля версий (а точнее, системы конфигурирования программного обеспечения - это более корректное название) применяются для:

• контроля над внесением изменений в код (в частности, ограничения одновременного внесения изменений несколькими разработчиками)
• отслеживания и хранения версий;
• сборки и интеграции проекта.

Разработка флэш-проектов здесь абсолютно не является исключением. Поэтому рассмотрим некоторые аспекты этой проблемы более подробно.

Системы контроля версий

Существуют разные системы контроля версий от разных производителей. Самыми популярными являются CVS, ClearCase, MS Visual SourceSafe. CVS - в каком-то смысле открытый стандарт, но для нее нет удобных (для использования во флэш-проектах) графических оболочек. ClearCase - очень сложная и дорогая система, которую вряд ли имеет смысл использовать для управления флэш-проектами. MS Visual SourceSafe (далее называемая сокращенно MS VSS) - неплохая и достаточно простая система с удобным графическим интерфейсом.

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

Выбор был сделан вполне тривиально: MS Visual SourceSafe - это наиболее простая система. Правда, позже мы обнаружили, что MS VSS очень хорошо подходит для флэш-проектов. Например, в ней по умолчанию запрещены multiple checkouts (которые не имеют смысла при работе с двоичными файлами *.fla), а также есть очень удобные инструменты links и shadow folders, о которых мы расскажем далее.

Контроль над внесением изменений в код

Что для флэш-проектов является характерным - так это то, что исходные файлы имеют двоичный формат, что отнюдь не способствует совместной работе над ними и последующему слиянию ( merge ) файлов. Что ж, тем жестче нужно ограничивать одновременные изменения .fla-файлов (и запрещать unreserved, или multiple, check-outs ).

MS VSS по умолчанию и работает в таком режиме.

Разумно также (как уже неоднократно замечалось ранее) выносить максимум кода за рамки *.fla-файлов (в include -файлы). Тогда можно настроить возможность одновременной работы над этими файлами.

Интеграция

При интеграции очень удобно пользоваться такими механизмами (или их аналогиями), как ссылки ( links ) и теневые папки ( shadow folders ), которые есть в VSS.

Ссылки VSS - это аналог жестких ссылок ( hard link ) в файловых системах (см. ранее в этой лекции). Теневые папки позволяют "отобразить" все изменения в каком-то проекте VSS на каталог файловой системы, то есть обновить там все файлы.

Приведем пример. Предположим, вы изменили файл core.fla и выполнили check-in (внесли изменения). Поскольку на core.fla существуют ссылки в проектах $/core/ и $/author-shared, он изменился сразу в двух проектах. У проекта $/core/ настроен shadow folder в \\myshare\myProject\src (здесь под \\myshare имеется в виду абстрактный сетевой путь, являющийся корнем для флэш-проектов), а у проекта $/author-shared - в \\myshare\\myProject\author-shared, в результате чего файл изменился сразу в двух каталогах: в архивном каталоге проекта ( src ) и каталоге, который подключен в качестве сетевого диска (например, как M:) и из которого обновляются все флэш-ролики при компиляции ( author-shared ).

Точно так же с помощью links и shadow folders можно обновлять *.swf-файлы, причем если вы еще используете жесткие ссылки в файловой системе, то *.swf-файлы могут автоматически обновиться в рабочих директориях дизайнеров.