dónde save instantáneas de compilation en svn

Necesitamos archivar la producción de compilation de nuestro proyecto (en nuestro caso, un único file ejecutable de aproximadamente 1 MB de tamaño) de forma controlada.

NOTA: El resultado práctico de esto es que para cualquier salida de compilation lanzada, necesito archivar una copy inmutable de ella indefinidamente. (por ejemplo, si construimos desde r993, r1014, r1205 y r1293 de nuestro tree fuente, necesito mantener un resultado de compilation para cada uno).

Es natural que usemos Subversion para esto porque tenemos un server en ejecución. Lo que no es natural es dónde poner la salida de compilation.

  1. Verifique en un área del tree fuente -> no es bueno, porque complica las actualizaciones / fusiones / etc.

  2. Cree un área especial en el repository asociado con el tree fuente, por ejemplo:

    project-foo/ branches/ tags/ trunk/ build/ <-- released executables go here (along with metadata containing source references) 

    Realmente no necesitamos twigs o tags para la salida ejecutable; Solo necesito un lugar que sea una instantánea inmutable a la que pueda hacer reference (en el caso de SVN, por path y rev #)

  3. Cree un área especial en el repository asociada libremente con el tree fuente, por ejemplo:

     project-foo/ branches/ tags/ trunk/ project-foo-build/ <-- released executables go into a subdir: branches/ tags/ trunk/ 
  4. Use otro progtwig en lugar de SVN. ??? Sea lo que sea, necesita apoyar las ideas de

    • datos inmutables
    • metadatos asociados con los datos
    • varias versiones del mismo tipo de cosas (por ejemplo, el ejecutable de compilation para el proyecto foo)

¿Alguna sugerencia?

Me estoy inclinando por la idea n. ° 2, pero quería dar un paso atrás y tener una mejor idea de las diversas ventajas / desventajas.


* Necesitamos hacer esto porque necesitamos mantener el resultado de construcción exacto que se usó bajo ciertas circunstancias. Este es un código embedded cargado en el hardware. Lo ideal es que el resultado de compilation sea una function repetible del tree de origen, de modo que si construye dos veces con el mismo tree de origen, produce el mismo resultado. Lamentablemente, existe el riesgo de que este no sea el caso, por ejemplo, a medida que se actualizan comstackdores u otras herramientas de compilation.

No necesita almacenar los files reales en el repository de Subversion para realizar un seguimiento de ellos con un grado razonable de confianza. Lo que puede hacer es crear los files de salida, calcular un hash (por ejemplo, SHA1) del contenido del file y luego almacenar el nombre de file y el valor hash en el repository.

Siempre que su almacenamiento de files de salida esté respaldado al less al mismo nivel que su repository de Subversion para que no los pierda, puede estar seguro (dentro de un grado razonable) de que los files proporcionados fueron el resultado generado por la compilation en el momento en que grabó el hash.

Varias de tus opciones funcionarían bien, pero votaría por el # 4.

Mi compañía también crea y lanza packages SW integrados, y requerimos el almacenamiento de los binarys reales que entregamos (junto con la documentation de compilation, varios formattings de files de salida, etc.) además de labelr la revisión SW en el repository.

Estoy de acuerdo con la respuesta de Greg Hewgill con respecto a colocarlos en un server de files en un directory distinto. Si, por otro lado, está buscando una herramienta SCM más completa, Redmine es una gran opción de código abierto. Redmine proporciona enlaces SVN (o Hg, Git, etc …), seguimiento de problemas, gestión de files, etc. No es solo un repository de files, sino una herramienta SCM más completa.

Además, wikipedia tiene una list completa de herramientas de SCM , muchas de las cuales pueden configurarse fácilmente para actuar como una herramienta de almacenamiento entregable.

Puede hacer la compilation, svn add los files binarys a su copy de trabajo y luego labelr directamente desde su copy de trabajo :

 build.bat svn add bin\* svn cp . http://example.com/svn/myproject/tags/xy -m "tagging release xy" svn revert -R . 

De esta forma, los binarys aparecen en las tags de lanzamiento, pero nunca en el tronco.

Tenga en count que svn revert al final. Esto es necesario porque el svn status aún mostrará los cambios realizados por svn add . No quieres esos cambios en el maletero.

Como dices, no es natural usar SVN para build productos, porque una buena práctica es tener solo código fuente en tu repository. Mejor sería nombrar el resultado de compilation sin ambigüedades (project-branch-revision), nombrado por su process de compilation, y archivar el resultado de compilation de una manera clásica (server de files).