Control de versiones para proyectos de Adobe Flash

Question

Estoy trabajando con un proyecto de 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) usamos subversion para control y 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 que se puede revertir a versiones anteriores) ya que los archivos FLA se almacenan como solo binarios de los que no podemos obtener diferencias significativas.

Estamos colocando la mayor cantidad de código posible en archivos AS que podemos administrar correctamente mediante subversión, 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), todavía mantenemos una gran colección de archivos FLA que necesitamos administrar.

He visto Adobe Version Cue y si bien no entiendo realmente lo que hace en términos de control de versiones, ¿mover nuestros proyectos Flash a hosting en Version Cue me dará un mejor control que el actual de Subversion?

Además, si las personas pueden compartir su experiencia y sugerencias sobre el control de versiones de proyectos Flash, será de gran ayuda.

Answer 1

He luchado con esto por mí mismo, y no puedo decir otra cosa que:

1. Sin código en acuerdos sobre el terreno, siempre
2. contenido Divide semánticamente en acuerdos sobre el terreno por separado en su caso
3. Hacer un documento de cambio para FLA e ingrese una nota para cada cambio individual.

El primer punto es suficientemente obvio. El segundo es reconocer que no hay forma de evitar el hecho de que los FLA son blobs binarios que contienen todos tus recursos visuales y no funcionan bien con las versiones, pero puedes reconocer el hecho de que algunos contenidos cambian frecuentemente mientras que otros tienden a crearse una vez. y luego 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 el contenido estable e inestable se reflejará en sus archivos versionados.

Tenga en cuenta que incluso si no puede cargar activos en el tiempo de ejecución, compartir en tiempo de compilación todavía le permite dividir los activos en un número arbitrario de FLA. (El uso compartido de 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). Cómo dividir las cosas dependerá de su proyecto. Lo mejor que puedo sugerir es hacer divisiones semánticamente, quizás una FLA para cada personaje, una FLA para cada sección o una FLA para cada elemento de interfaz, etc. Como con 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, no hay forma de evitar un documento de cambio. Mi forma preferida es verificar los 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 que mantenga 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 doloroso para algunos contenidos, también es útil designar ciertos FLA como " inestable ", y no molestarse con una lista de cambios. Pero si dichos 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 sobre el cambio a un formato FLA basado en texto en una versión futura, pero hasta que llegue, no hay una solución fácil.

Answer 2

Por lo que entiendo de Adobe Version Cue, no obtendrá nada más de lo que svn le está dando. (Por supuesto, solo he escuchado historias de horror de Version Cue y no las he usado).

Después de haber trabajado en grandes proyectos de Flash con svn before (grandes equipos y grandes despliegues), el mejor consejo que puedo darles usted es:

• Bien, su cliente está exigiendo todos estos FLA, pero ¿por qué? Puede que ya haya hecho esto, pero intente reducir un poco sus requisitos técnicos: ¿qué creen que están obteniendo de este requisito?

• Designe UNA persona para ser el administrador de lanzamiento de la aplicación Flash. Ellos serán los encargados de verificar el código correcto de svn, compilarlo y asegurarse de que llegue a la implementación general de la aplicación. También serán una respuesta para saber qué revisión está en qué entorno (esto se puede automatizar fácilmente).

• Ponga tan poco código y recursos en la FLA como sea posible. Debería cargar imágenes y otros activos de fuentes externas y luego adjuntarlos a los MC y Sprites apropiados.

• Si es posible, mantenga los equipos en pequeños trozos discretos. Esto disminuye las posibilidades de cambios conflictivos en los FLA y aumenta las posibilidades de que todos sepan lo que está sucediendo.

• [Más de un ancho de banda, menos relacionado con esta pregunta] Trate sus FLA como bibliotecas o SDK si es posible. Si su demanda es cercana a "un sub-FLA por página" con un FLA maestro, entonces tienen sub-FLA adicionales que contienen los activos/widgets. De esta forma, las FLA de su página solo contienen código específico de la página, y no está recargando widgets cada vez que "cambia de página". (No prevé el navegador refrescante entre los interruptores de página.)

Es probablemente la pena señalar que se trata de soluciones en gran medida no técnicos. Aún no he encontrado una "muerte instantánea" por 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 patentado, que solo se compilará en un formato de propiedad diferente, es un mal vudú.

Answer 3

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

Si usted está construyendo un proyecto flash de código pesado, me gustaría ir con un ActionScript puro o flexión enfoque, usando archivos .fla solo para lo que son útiles (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 amigables para control de fuente.

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

Si eso no es posible, me temo que lo único que puede hacer es eliminar tantas cosas de las FLA como sea posible: el formato binario simplemente no es amigable con el código fuente.

Olvídese de Version Cue - Adobe no lo desarrollan más (No está incluido en los nuevos paquetes CS5)

Answer 4

He estado tratando de encontrar una manera de resolver este mismo problema, aquí es una posible solución. .fla's son sistemas de archivos reales. Si reemplaza la extensión .fla con .zip, puede descomprimir y exponer los archivos descomprimidos, a diferencia de "mostrar los contenidos del paquete" en un mac. Todo el contenido de la biblioteca reside dentro de un directorio de 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 iniciarse en flash siempre que tenga todos los contenidos descomprimidos de .fla que residan en el mismo directorio que el .xfl

Técnicamente usted debería ser capaz de trabajar en el archivo .xfl con todos los contenidos de la biblioteca rastreados y mantenidos en subversión.

Answer 5

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