sirve - Control de versiones para proyectos de Adobe Flash.

para que sirve macromedia flash (5)

He estado tratando de encontrar una manera de resolver este mismo problema, aquí hay una posible solución. .fla son sistemas de archivos reales. Si reemplaza la extensión .fla por .zip, puede descomprimir y exponer los archivos sin comprimir, a diferencia de "mostrar el contenido del paquete" en un mac. Todo el contenido de la biblioteca reside dentro de un directorio de la biblioteca con cada clip de película representado por un documento xml. Cada capa obtiene un nodo y los marcos dentro de una capa se representan como nodos secundarios. También hay un archivo .xfl que es la versión no comprimida de .fla que puede iniciar en flash siempre que tenga todos los contenidos descomprimidos de .fla que residen en el mismo directorio que .xfl

Técnicamente, debería poder trabajar en el archivo .xfl con todo el contenido de la biblioteca que se rastrea y mantiene en subversión.

Estoy trabajando con un proyecto Flash muy complejo que forma parte de una gama completa de servicios que implementamos para el uso de nuestros clientes. Para la mayoría de nuestras fuentes de software (Java, PHP, Javascript, HTML y algunos scripts de soporte en otros idiomas) utilizamos Subversion para el control y la administración de versiones, por lo que hacemos lo mismo para nuestros proyectos Flash, aunque obtenemos pocos beneficios de la versión. controlando eso (excepto la posibilidad de revertir a versiones anteriores), los archivos FLA se almacenan como archivos binarios de los que no podemos obtener diferencias significativas.

Estamos poniendo tanto código como sea posible en los archivos de AS que podemos gestionar adecuadamente usando Subversion, pero debido a los requisitos de nuestra arquitectura y nuestra estrategia de implementación (ambos no podemos cambiar debido a las necesidades de nuestros clientes), aún mantenemos una gran cantidad de recursos. colección de archivos FLA que necesitamos gestionar.

He analizado Adobe Version Cue y, si bien no entiendo realmente lo que hace en términos de control de versiones, ¿moveré nuestros proyectos Flash al alojamiento en Version Cue me dará un mejor control que el que actualmente recibo de Subversion?

Además, si la gente puede compartir su experiencia y sugerencias con respecto al control de versiones de proyectos Flash, será muy útil.

He luchado con esto yo mismo, y no puedo decirte nada más que:

Sin código en FLAs, nunca
Divida el contenido semánticamente en FLA separadas cuando sea apropiado
Cree un documento de modificación para los FLA e ingrese una nota por cada cambio.

El primer punto es bastante obvio. El segundo es reconocer que no se puede evitar el hecho de que las FLA son burbujas binarias que contienen todos sus recursos visuales y no funcionan bien con el control de versiones, pero puede reconocer el hecho de que algunos contenidos cambian con frecuencia mientras que otros tienden a crearse una vez. y luego se queda solo. Al dividir sus activos en diferentes FLA, puede mantener la gran mayoría de los cambios en un pequeño número de FLA inestables, y la diferencia entre contenido estable e inestable se reflejará en sus archivos versionados.

Tenga en cuenta que incluso si no puede cargar activos en tiempo de ejecución, el uso compartido en tiempo de compilación le permite dividir los activos en un número arbitrario de FLA. (El intercambio en tiempo de compilación a menudo se pasa por alto: si no está familiarizado con él, abra las propiedades de un MovieClip y consulte la sección "Fuente" en la parte inferior). La forma de dividir las cosas dependerá de su proyecto. Lo mejor que puedo sugerir es hacer divisiones semánticamente, tal vez una FLA para cada personaje, o una FLA para cada sección, o una FLA para cada elemento de la interfaz, etc. Como en todo desarrollo, el objetivo es agrupar los activos relacionados y eliminar la duplicación.

El tercer punto es que, dado que las diferencias son imposibles, simplemente no hay forma de evitar el cambio de un documento. Mi forma preferida es registrar las FLA en el control de versiones y anotar todos los cambios en la nota de check-in, pero los cambios también podrían estar en un documento separado. (Tenga en cuenta que es vital mantener ordenadas las bibliotecas en cada FLA, o que alguien que lea la descripción del cambio tenga problemas para encontrar el cambio). Sin embargo, dado que esto puede ser una molestia para algunos contenidos, también es útil designar ciertos FLA como " inestable ", y no molestarse con una lista de cambios. Pero si tales archivos tienen muchas dependencias en otros archivos, lo lamentará más tarde.

Desafortunadamente esto es todo lo que he descubierto hasta ahora. Adobe ha hablado de cambiar a un formato FLA basado en texto en una versión futura, pero hasta que llegue, no hay una solución fácil.

La respuesta de Adobe a esto está en el nuevo CS5 Flash. Use "guardar como" y elija .xfl de los tipos desplegables. Ahora puede trabajar en su proyecto y registrarlo a través de SVN. Seguiría dividiendo su código en archivos .as, pero de esta manera también se rastrearán los activos de su biblioteca. Básicamente, mantiene todo en el formato XML como flex mxml. Creo que esta es tu mejor opción.

Parece que estás atascado con archivos FLA debido a requisitos externos pero, por si acaso ...

Si está construyendo un proyecto flash de código pesado, me gustaría utilizar un ActionScript puro o un enfoque flexible, usando archivos .fla solo para lo que sirven (animación basada en la línea de tiempo).

Flex Builder / Flash Builder es un excelente entorno para crear proyectos Flash donde todo el código está en formatos de archivo compatibles con el código fuente.

Estamos en el proceso de trasladar todos nuestros reproductores multimedia basados en FLA a MXML (donde los componentes de Flex UI son útiles) y proyectos de ActionScipt puros. Los beneficios del control de la fuente son enormes.

Si eso no es posible, entonces me temo que lo único que puede hacer es sacar la mayor cantidad posible de FLA, ya que el formato binario simplemente no es compatible con el código fuente.

Olvide el cue de la versión: Adobe ya no lo desarrolla (no está incluido en los nuevos paquetes CS5)

Por lo que entiendo de Adobe Version Cue, no obtendrá nada más allá de lo que svn le ofrece. (Por supuesto, solo he escuchado historias de terror de Version Cue y no lo he usado).

Habiendo trabajado en grandes proyectos Flash con svn antes (grandes equipos y grandes implementaciones), el mejor consejo que puedo darles es:

Bien, tu cliente está exigiendo todas estas FLA, pero ¿por qué? Es posible que ya hayas hecho esto, pero intenta presionar un poco sus requisitos técnicos. ¿Qué creen que están obteniendo de este requisito?
Designe a UNA persona para que sea el administrador de versiones de la aplicación Flash. Serán responsables de verificar el código correcto de svn, de compilarlo y de asegurarse de que llegue al despliegue general de la aplicación. También serán la respuesta para saber qué revisión se encuentra en qué entorno (esto se puede automatizar fácilmente).
Ponga tan poco código y recursos en la FLA como sea posible. Debe cargar imágenes y otros recursos de fuentes externas y luego adjuntarlos a los MC y Sprites apropiados.
Si es posible, mantenga a los equipos en partes pequeñas y discretas. Esto disminuye las posibilidades de cambios conflictivos en las FLA y aumenta las posibilidades de que todos sepan lo que está pasando.
[Más de una nota de ancho de banda, menos relacionada con esta pregunta] Si es posible, trate sus FLA como bibliotecas o SDK. Si su demanda está cerca de "una sub-FLA por página" con una FLA maestra, entonces tenga sub-FLA adicionales que contienen los activos / widgets. De esa manera, los FLA de su página solo contienen un código específico de la página, y no está volviendo a cargar los widgets cada vez que "cambia de página". (No se supone que el navegador se actualice entre los cambios de página).

Probablemente vale la pena señalar que estas son soluciones en gran medida no técnicas. Todavía tengo que encontrar un "one shot kill" para el problema de trabajar con archivos binarios en los sistemas de control de revisiones, especialmente los archivos binarios que realmente son código fuente. Y ese es realmente el factor decisivo: la idea de almacenar el código fuente en un formato binario propietario, para que solo se compile en un formato propietario diferente, es un vudú malo.