Контроль версий для проектов Adobe Flash

Я работаю с очень сложным проектом Flash, который является частью полного спектра услуг, которые мы развертываем для использования наших клиентов. Для большинства наших источников программного обеспечения (Java, PHP, Javascript, HTML и некоторых поддерживающих скриптов на других языках) мы используем subversion для управления версиями и управления, поэтому мы делаем то же самое для наших Flash-проектов, хотя мы мало выигрываем от версии (кроме возможности вернуться к предыдущим версиям), поскольку файлы FLA хранятся как двоичные файлы, из которых мы не можем получить значимые отличия.

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

Я просмотрел Adobe Version Cue и, хотя я не совсем понимаю, что он делает с точки зрения контроля версий, переместит наши Flash-проекты на хостинг на Version Cue, даст мне лучший контроль, а теперь я получаю от Subversion?

Кроме того, если люди могут поделиться своим опытом и предложениями относительно контроля версий проектов Flash, это будет очень полезно.

Ответ 1

Я сам боролся с этим, и я не могу сказать вам ничего, кроме:

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

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

Обратите внимание, что даже если вы не можете загружать активы во время выполнения, совместное использование времени по-прежнему позволяет разделить активы на произвольное число FLA. (Совместное использование времени часто игнорируется - если вы не знакомы с ним, откройте свойства MovieClip и посмотрите раздел "Источник" внизу.) Как разделить все будет зависеть от вашего проекта. Самое лучшее, что я могу предложить, - это сделать семантические разделения - возможно, один FLA для каждого символа или один FLA для каждого раздела или один FLA для каждого элемента интерфейса и т.д. Как и во всех разработках, цель состоит в группировании связанных активов и устранении дублирования.

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

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

Ответ 2

Adobe ответит на это в новой Flash CS5. Используйте "save as" и выберете .xfl из типов pull down. Теперь вы можете работать над своим проектом и проверять его через SVN. Я все равно вырвал бы ваш код в файлах .as, но так же отслеживаются ваши библиотечные ресурсы. Он в основном сохраняет все в разметке xml, например, flex mxml. Я думаю, что это ваш лучший вариант.

Ответ 3

Звучит так, будто вы застряли с файлами FLA из-за внешних требований, но на всякий случай...

Если вы создаете тяжелый флеш-проект с кодовым кодом, я бы пошел с использованием чистого ActionScript или Flex-подхода, используя файлы .fla только для того, что им подходит (анимация на основе временной шкалы)

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

Мы собираемся перенести все медиаплееры на FLA на MXML (где компоненты Flex UI полезны) и чистые проекты ActionScipt. Преимущества управления источником Thje огромны.

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

Забудьте о версии cue - Adobe больше не разрабатывает его (он не входит в новые пакеты CS5)

Ответ 4

Из того, что я понимаю в Adobe Version Cue, он не даст вам ничего, кроме того, что дает вам svn. (Конечно, я только слышал ужасные истории Version Cue и на самом деле не использовал его.)

Работая над крупными проектами Flash с svn before (большие команды и большие развертывания), лучший совет, который я могу вам дать:

Хорошо, ваш клиент требует всех этих FLA, но почему? Возможно, вы уже это сделали, но попробуйте немного вернуться к своим техническим требованиям - что, по их мнению, они получают от этого требования?
Назначьте ОДНОГО человека, чтобы быть менеджером выпуска для приложения Flash. Они будут нести ответственность за проверку правильного кода из svn, его создание и обеспечение того, чтобы он попадал в развертывание общего приложения. Они также будут отвечать за знание того, какая ревизия находится в какой среде (это может быть легко автоматизировано).
Поместите как можно меньше кода и активов в FLA. Вы должны загружать изображения и другие активы из внешних источников, а затем присоединять их к соответствующим MC и Sprites.
Если это вообще возможно, держите команды в небольших дискретных кусках. Это уменьшает вероятность противоречивых изменений в FLA и повышает шансы каждого на то, что происходит.
[Больше заметки о пропускной способности, менее связанной с этим вопросом] Относитесь к своим FLA-библиотекам или SDK, если это вообще возможно. Если их спрос близок к "одному суб-FLA на странице" с мастер-FLA, тогда есть дополнительные суб-FLA, которые хранят активы/виджеты. Таким образом, ваши FLA страницы страницы содержат только код страницы, и вы не перезагружаете виджеты каждый раз, когда вы "переключаете страницы". (Не требует обновления браузера между переключателями страниц.)

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

Ответ 5

Я пытаюсь найти способ решить эту же проблему, вот возможное решение..fla - это фактические файловые системы. Если вы замените расширение .fla на .zip, вы можете распаковать и разоблачить несжатые файлы, не похожие на "показать содержимое пакета" на Mac. Все содержимое библиотеки находится внутри каталога библиотеки с каждым мувиклипом, представленным XML-документом, каждый слой получает node и кадры внутри слоя, представляемого в виде дочерних узлов. Существует также .xfl файл, который является несжатой версией .fla, которую вы можете запустить во flash, если у вас есть все распакованное содержимое .fla, находящееся в том же каталоге, что и .xfl

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