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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

• Назначьте ОДНОГО человека менеджером по выпуску приложения Flash. Они будут отвечать за проверку правильного кода из svn, его сборку и проверку того, что он попадет в общее развертывание приложения. Они также будут ответом на вопрос о том, какая редакция находится в какой среде (это может быть легко автоматизировано).

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

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

• [Больше информации о пропускной способности, меньше относится к этому вопросу] Обращайтесь с вашими FLA как с библиотеками или SDK, если это возможно. Если их спрос близок к «одному суб-FLA на страницу» с основным FLA, то есть дополнительные суб-FLA, которые содержат ресурсы / виджеты. Таким образом, ваши FLA-страницы содержат только код конкретной страницы, и вы не перезагружаете виджеты каждый раз, когда вы «переключаете страницы». (Предполагается, что браузер не обновляется между переключателями страниц.)

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