La mejor forma de ramificar proyectos de Flex utilizando subversión

Este es nuestro problema, somos una tienda de Flex que usa .NET para la lógica del lado del server. Usamos subversión para nuestro control de fuente y subeclipse en Flex Builder, pero todavía somos bastante nuevos para usar control de fuente y mucho less subversión. La ramificación y la fusión parecen funcionar muy bien en el lado de .NET, pero estamos teniendo problemas en el lado de Flex debido a que el swf final se está creando en nuestra máquina local.

La pregunta es, ¿cómo se ve un flujo de trabajo habitual para trabajar con Flex y SVN? Particularmente, ¿cómo te ramificas y dónde construyes?

Personalmente, mantengo el código fuente de Flash / Flex en un repository SVN separado que está lejos de lo que se implementa en cualquier tipo de server web. De esa forma puedo crear twigs y tags específicamente para mi aplicación Flash / Flex. También tiendo a publicar cualquier file SWF directamente en mi copy local del repository de implementación. No tiene sentido para mí mantener un file SWF publicado bajo control de versión a less que sea parte de lo que se implemente en el server. No me gusta seguir cometiendo un SWF en mi repository de código fuente de Flash porque ocupa espacio innecesario y todo el código fuente debe representar la última versión, no el SWF resultante.

Usamos una estructura de directorys como esta

+server-side-app --trunk --tags --branches +flex-client-app --trunk --tags --branches 

Yo recomendaría algo así para ti.

Probablemente quiera ramificar su proyecto junto con su proyecto .Net para que sus lanzamientos flexibles sean consistentes con la lógica de su server.

Estoy de acuerdo con Matt W. En AKQA tenemos ubicaciones de svn cuatro de nuestras fonts y resources. Configuramos un svn ignore para las carpetas bin de un proyecto. De esta forma, no estamos verificando ningún swf, lo que significa que cuando actualizamos no obtenemos ni swfs ni files de salida.

Una buena apuesta es estudiar la continuous integration con algo como el control de crucero. Construimos nuestra salida en el server que genera todos los files en una location en el server. Hay muchos otros beneficios de continuous integration y vale la pena tenerlos