Управление версиями для проектов Adobe Flash
Я работаю с очень сложным Flash-проектом, который является частью полного спектра услуг, которые мы развертываем для использования нашими клиентами. Для большинства наших источников программного обеспечения (Java, PHP, Javascript, HTML и некоторые вспомогательные скрипты на других языках) мы используем subversion для управления версиями и управления, поэтому мы делаем то же самое для наших флеш-проектов, хотя мы получаем мало преимуществ от управления версиями, которые (кроме возможности вернуться к предыдущим версиям), поскольку файлы FLA хранятся как только двоичные файлы, из которых мы не можем получить значимые различия.
мы помещаем столько кода, сколько можем, в файлы, которыми мы можем правильно управлять с помощью subversion, но из-за требований нашей архитектуры и нашей стратегии развертывания (оба мы не можем изменить из-за потребностей наших клиентов), мы по-прежнему поддерживаем большую коллекцию файлов FLA, которыми нам нужно управлять.
Я посмотрел на Adobe Version Cue и, хотя я действительно не понимаю, что он делает с точки зрения версии контроль, будет ли перемещение наших флеш-проектов на хостинг по версии Cue даст мне лучший контроль, чем я сейчас получаю от Subversion?
также-если люди могут поделиться своим опытом и предложениями относительно контроля версий Flash-проектов, это будет очень полезно.
5 ответов
Я сам боролся с этим, и я не могу сказать вам ничего, кроме:
- нет кода в FLAs, когда-либо
- разделите содержимое семантически на отдельные флаконы, где это уместно
- сделайте документ изменения для FLAs и введите примечание для каждого изменения.
первый момент достаточно очевиден. Во-вторых, следует признать, что невозможно обойти тот факт, что FLAs-это двоичные капли, которые содержат все ваши визуальные активы и не очень хорошо играть с версиями, но вы можете признать тот факт, что некоторые содержимое часто меняется, в то время как другие, как правило, создаются один раз, а затем оставить в покое. Разделив свои активы на разные FLAs, вы можете сохранить подавляющее большинство изменений в небольшом количестве нестабильных FLAs, и разница между стабильным и нестабильным контентом будет отражена в ваших версионных файлах.
обратите внимание, что даже если вы не можете загружать активы во время выполнения, совместное использование времени компиляции все еще позволяет разделить активы в произвольное число FLAs. (Совместное использование времени компиляции часто упускается из виду - если вы не знакомы с ним, откройте свойства MovieClip и проверьте раздел "источник" внизу.) Как разделить вещи будет зависеть ваш проект. Лучшее, что я могу предложить, - это семантически разделить их-возможно, один FLA для каждого символа, или один FLA для каждого раздела, или один FLA для каждого элемента интерфейса и т. д. Как и все разработки, цель состоит в том, чтобы сгруппировать связанные активы и устранить дублирование.
третий момент заключается в том, что, поскольку различия невозможны, нет никакого способа сохранить документ изменения. Мой предпочтительный способ-проверить FLAs на управление версиями и отметить все изменения в примечании регистрации, но изменения также могут быть в отдельном документе. (Обратите внимание, что очень важно, чтобы Вы содержали библиотеки в каждом порядке FLA, или кто-то, читающий описание изменения, будет иметь проблемы с поиском изменения.) Однако, поскольку это может быть болью для некоторого содержимого, это также полезно обозначить определенные FLAs как "нестабильные" и не беспокоиться о списке изменений. Но если такие файлы имеют много зависимостей от других файлов, вы пожалеете об этом позже.
к сожалению, это все, что я обнаружил до сих пор. Adobe говорила о переходе на текстовый формат FLA в будущей версии, но до тех пор, пока это не произойдет, нет простого решения.
ответ Adobe на это находится в новой вспышке CS5. Используйте "сохранить как" и выберите .xfl из типов тянут вниз. Теперь вы можете работать над своим проектом и проверять его через SVN. Я все равно взломаю твой код.как файлы, но таким образом ваши библиотечные ресурсы также отслеживаются. Он в основном держит все в разметке xml, как flex mxml. Я думаю, это твой лучший вариант.
похоже, вы застряли с FLA-файлами из-за внешних требований, но на всякий случай...
Если вы создаете проект flash с тяжелым кодом, я бы пошел с чистым подходом actionscript или flex, используя .fla файлы только для того, что они хороши для (анимация на основе временной шкалы)
Flex Builder / Flash Builder-отличная среда для создания Flash-проектов, где весь код находится в удобных для управления версиями форматах файлов.
мы находимся в процессе перемещение всех наших медиаплееров на основе FLA в MXML (где полезны компоненты Flex UI) и чистые проекты ActionScipt. Радио преимущества управления источником огромны.
Если это невозможно, то я боюсь, что единственное, что вы можете сделать, это переместить как можно больше вещей из FLAs - двоичный формат просто не подходит для управления версиями.
забудьте о версии cue-Adobe больше не разрабатывает ее (она не входит в новые пакеты CS5)
из того, что я понимаю из Adobe Version Cue, это не даст вам ничего, кроме того, что svn дает вам. (Конечно, я слышал только ужасные истории о версии Cue и на самом деле не использовал ее.)
поработав над большими флеш-проектами с svn раньше (большие команды и большие развертывания), лучший совет, который я могу вам дать:
хорошо, ваш клиент требует все эти фляги, но почему? Возможно, вы уже сделали это, но попробуйте отодвинуть их техническое требование немного - что они думают, что они получают от этого требования?
назначьте одного человека менеджером выпуска для приложения Flash. Они будут отвечать за проверку правильного кода из svn, его построение и обеспечение его попадания в общее развертывание приложения. Они также будут ответом за знание того, какой пересмотр в какой среде (это может быть легко автоматизировано).
совсем немного код и активы в FLA, насколько это возможно. Вы должны загружать изображения и другие ресурсы из внешних источников, а затем присоединять их к соответствующим MCs и спрайтам.
Если это вообще возможно, держите команды в небольших дискретных кусках. Это уменьшает шансы конфликтующих изменений в FLAs и увеличивает шансы каждого знать, что происходит.
[больше из примечания ширины полосы частот, меньше связанного с этим вопросом] обработайте ваши FLAs как библиотеки или SDK, если это вообще возможно. Если их спрос близок к "одному суб-FLA на страницу" с master FLA, то есть дополнительные суб-FLA, которые держат активы/виджеты. Таким образом, ваши страницы FLAs содержат только код страницы, и вы не перезагружаете виджеты каждый раз, когда вы "переключаете страницы". (Предполагает отсутствие обновления браузера между переключателями страниц.)
вероятно, стоит отметить, что это в основном нетехнические решения. Я еще не нашел "один выстрел убить" для проблема работы с двоичными файлами в системах контроля версий-особенно с двоичными файлами, которые действительно являются исходным кодом. И это действительно решающий момент: идея хранения исходного кода в проприетарном двоичном формате, который должен быть скомпилирован только в другой проприетарный формат, является плохим вуду.
Я пытался найти способ решить эту же проблему, вот возможное решение. .fla-это фактические файловые системы. Если вы замените .расширение fla С.zip вы можете распаковать и выставить несжатые файлы, не похожие на "Показать содержимое пакета" на mac. Все содержимое библиотеки находится внутри каталога библиотеки, и каждый movieclip представлен xml-документом, каждый слой которого получает узел и фреймы в слое, представленном как дочерние узлы. Существует также .футбольной Лиги файл с несжатой версией .fla, который вы можете запустить во flash, пока у вас есть все распакованное содержимое.fla, проживающий в том же каталоге, что и .футбольной Лиги
технически вы должны быть в состоянии работать на .файл xfl со всем содержимым библиотеки отслеживается и поддерживается в subversion.