Versión de compilation contra número de revisión

Tengo una aplicación asp.net/C# que usa subversion para el control de código fuente.

Mi aplicación aumenta automáticamente su AssembleVersion y AssemblyFileVersion en cada compilation que funciona como un amuleto, y muestra el número de compilation en el lado de la administración del sitio.

Hacemos un seguimiento de AssembleVersion y AssemblyFileVersion cuando hacemos la implementación, sin embargo, cuando surge un problema y tenemos que retroceder a una determinada versión, no tenemos idea de qué revisión apuntar en subversión.

Tengo algunas ideas:

  1. Guarde AssembleVersion como comentario en cada file
  2. Tener una palabra key en los comentarios de compromiso que get's replace por AssembleVersion en cada commit (aún necesita averiguar cómo hacerlo)

Cualquier ayuda y sugerencias serán apreciadas

Actualizado: la opción "1" es en realidad una idea estúpida, porque esto significará que cada vez que construya, todos los files se marcarán como actualizados y cuando me comprometo, cada file se actualizará

Cuando construyo, pongo ese número de compilation en todas partes.

  • Lo puse en una label en svn.
  • Lo pongo en los metadatos de la Asamblea de cada asamblea que construyo.
  • Lo agrego al final del nombre de file en mis instaladores.
  • Lo puse en el pie de página de cada una de las páginas web implementadas.
  • Lo puse en el pie de página de mis informes.
  • Lo puse en la pantalla de bienvenida de mis aplicaciones del lado del cliente.
  • Lo puse en la pantalla de bienvenida para mis instaladores.

Lo único que no pongo es mi café, que tomo negro .

Todo esto le permite a un desarrollador saber de un vistazo exactamente de dónde viene el código para lo que está viendo, ya sea que esté viendo una página web, o mirando las properties de uno de los ensamblados construidos en Explorer, o lo que sea.

Las tags no son realmente útiles si construyes a menudo. ¿Quizás encuentre una manera de actualizar la versión de la Asamblea basada en la revisión svn en su lugar? También incluya el nombre de la twig, porque comparten las revisiones.

Y debería poder extraer la versión ensamblada en sus páginas ASP.NET e imprimirla programáticamente en un pie de página o algo así.

Puede labelr el tronco de Subversion con AssembleVersion o AssemblyFileVersion, lo que tenga más sentido.

También puede realizar un seguimiento del número de revisión de Subversion de la misma manera que actualmente realiza un seguimiento de AssembleVersion y AssemblyFileVersion cuando realiza la implementación.

Aplique una label a su tree fuente una vez que haya actualizado AssemblyVersion y AssemblyFileVersion .

Podrías "ramificar para liberar". Antes de crear una versión de lanzamiento, puede ramificar el tronco y luego crear una label en la nueva twig con el número de versión de lanzamiento.

  + release tag / +--------------------- release branch / ----------+----------------------------------------------------- trunk 

Esto le permitiría realizar un seguimiento de todas las publicaciones individuales en SVN. También le permitiría realizar correcciones de errores aisladas en las twigs de publicación que podrían lanzarse como parches. La corrección de errores podría fusionarse de nuevo en el tronco.

  + + patch release tag / / +-----------------+-+---- release branch / | merged fix into trunk... ----------+----------------------------------------------------- trunk 

Las tags / twigs son definitivamente el enfoque recomendado aquí.

También puede (o adicionalmente) include el número de revisión svn en su AssemblyInfo. Un enfoque es usar la tarea AssemblyInfo del proyecto msbuildtasks en http://msbuildtasks.tigris.org

Para get más información, google msbuild svn revision assemblyinfo

Entonces podría hacerlo sin tags / twigs, ya que siempre puede verificar una revisión específica y / o crear una twig a partir de una revisión específica.

Otra opción es usar la última revisión modificada como su número de compilation. Esto significa que cada vez que construyas tu auto-tag. Es fácil con hudson / jenkins ya que tiene una variable de entorno SVN_REVISION. El problema es que el número de revisión es muy grande y las discusiones en el pasillo sobre 1.0.0.20456 frente a 1.0.0.20489 son un bocado.