SVN: ¿Liberar rama y externos?
release-management build-server (5)
Estoy haciendo ramas de lanzamiento / estables copiando también los elementos externos para que la rama se vuelva completamente independiente del tronco. Los externos se copian mediante svn usando
svn copia - padre
... a su respectivo punto de montaje. los elementos externos no revisados usan la revisión en la que deseas enraizar tu rama; Los elementos externos revisados utilizaron su revisión especificada en la copia. svn: la (s) propiedad (es) externa (s) debe ser eliminada en la nueva rama.
Algunos scripts (perl para mí) pueden ayudar a automatizar esto. Hazme un ping si necesitas más información sobre esto.
Tenemos dos sitios web para el mismo cliente (sitio www principal y otro para el sitio de comercio electrónico que se encuentra en un servidor separado) que usan una parte de código compartida (varias características / estilos / javascript, etc.). Actualmente gestionamos esto teniendo el código compartido como proyectos separados (en los mismos repositorios) en SVN y usando svn: externals para juntar la rama de cada uno de estos en los dos proyectos del sitio web.
Acabamos de crear dos sucursales de lanzamiento, una para cada uno de los dos sitios. Todo se compromete con el troncal para cada uno de los sitios de manera normal cuando se trabaja y cuando está "listo para funcionar", lo fusionamos en la rama de lanzamiento de ese sitio. Funciona bien, pero hoy modificamos algunos de los códigos compartidos y notamos que la versión de lanzamiento se activó de inmediato cuando hicimos una actualización de la versión de lanzamiento. Esto no es lo que queríamos :(
Así que cualquier idea de cómo podemos resolver este problema. Usamos elementos externos para SECAR el uso compartido del código, pero ¿hay alguna otra forma? Tenga en cuenta que en esta pregunta ( ¿Cómo puedo bifurcar en SVN y hacer que se bifurque mi svn: carpetas externas también? ) Mencionan que los elementos externos son malos y que deberíamos estar usando un proceso de compilación diferente, pero no se menciona qué debería ser.
Tenemos CruiseControl.net ejecutando nuestras compilaciones y estamos deseosos de obtener esta tuerca rajada. ¿Alguien tiene alguna idea sobre un proceso mejor?
Aclamaciones
Pete
ACTUALIZACIÓN: Desde entonces hemos pasado a utilizar Mercurial (Fogcreek''s Kiln) para nuestro control de fuente. Mercurial también tiene la idea de sub-repos, así que seguimos esa ruta con nuestro proyecto allí también. Sin embargo, tiene un costo, la bifurcación se hace realmente difícil, como lo es etiquetar y simplemente mantener todo actualizado. Nuestro último método es reunir ambos proyectos en uno solo, incluyendo todos los repositorios compartidos. Esto nos da un "megaproyecto" que ralentiza el tiempo de clonación (consulte en SVN), pero lo hacemos tan raramente que las ventajas de no tener que lidiar con sub-repos hacen que valga la pena. Ahora utilizamos el cambio / cambio de funciones en lugar de la bifurcación, lo que también simplifica enormemente nuestro desarrollo.
Otro lado tiene algunos buenos consejos, pero en realidad está usando svn: externals como un sistema de gestión de dependencias para hombres pobres. Se está haciendo un anti-patrón hacky algo viable para los disciplinados.
Es absolutamente correcto que svn: externals no es el camino.
Una cosa más en que pensar, si se mantiene en esa ruta, a menos que sus etiquetas svn sean atómicas (a través de un enlace de confirmación previa), querrá especificar la revisión y la etiqueta.
En este momento estoy sufriendo un shock por haber heredado algunas cosas de .NET, me hace extrañar mucho a Maven. Incluso me conformaría con un lío de hormiga / hiedra.
Es posible que desee revisar https://www.nuget.org/
Puede hacer svn update --ignore-externals si no desea que se actualicen los externos.
Sí, el uso de elementos externos apuntados a una revisión o etiqueta específica es el camino a seguir. Puede encontrarlo fácilmente simplemente leyendo el manual de svn en las partes externas ... ¡RFD! También, es casi una página larga ... :)
Si entiendo correctamente tienes algo como la siguiente estructura:
- Proyecto 1
- el maletero
- biblioteca (a través de
svn:externals library svn://repo/library)
- biblioteca (a través de
- ramas
- release1
- biblioteca (a través de
svn:externals library svn://repo/library)
- biblioteca (a través de
- release2
- biblioteca (a través de
svn:externals library svn://repo/library)
- biblioteca (a través de
- release1
- el maletero
- proyecto2
- el maletero
- biblioteca (a través de
svn:externals library svn://repo/library)
- biblioteca (a través de
- ramas
- release1
- biblioteca (a través de
svn:externals library svn://repo/library)
- biblioteca (a través de
- release1
- el maletero
- biblioteca
Supongo que está configurando svn:externals en / project1 / trunk to / library. Si luego combina la revisión con el svn:externals a / project1 / branch / release1 y actualiza esa rama, obtendrá automáticamente la última versión de la biblioteca. Por defecto, svn: externals obtendrá la revisión HEAD del enlace.
Puede definir el svn:externals para vincular a una revisión específica, como esto: svn:externals -r123 library svn://repo/library . Esto significa que el enlace externo siempre apuntará a esa revisión específica. Por lo tanto, puede usar este tipo de enlace svn:externals en la rama de su versión de forma segura sin tener que preocuparse de que el código de la biblioteca compartida se actualizará a menos que cambie manualmente el svn:externals
Probablemente, una mejor manera sería usar etiquetas para la biblioteca compartida y un enlace a una etiqueta específica. En este caso obtendrías la siguiente estructura de repositorio:
- Proyecto 1
- el maletero
- biblioteca (a través de
svn:externals library svn://repo/library/tags/version3)
- biblioteca (a través de
- ramas
- release1
- biblioteca (a través de
svn:externals library svn://repo/library/tags/version1)
- biblioteca (a través de
- release2
- biblioteca (a través de
svn:externals library svn://repo/library/tags/version2)
- biblioteca (a través de
- release1
- el maletero
- proyecto2
- el maletero
- biblioteca (a través de
svn:externals library svn://repo/library/tags/version2)
- biblioteca (a través de
- ramas
- release1
- biblioteca (a través de
svn:externals library svn://repo/library/tags/version1)
- biblioteca (a través de
- release1
- el maletero
- biblioteca
- etiquetas
- versión 1
- versión 2
- version3
- etiquetas