SVN: twig de liberación y externos?

Tenemos dos sitios web para el mismo cliente (el sitio principal de www y otro para el sitio de comercio electrónico que se encuentra en un server independiente) que usan una porción compartida de código (varias características / styles / javascript, etc.). Actualmente lo gestionamos teniendo el código compartido como proyectos separados (en el mismo repository) en SVN y usando svn: externals para extraer la twig de cada uno de estos en los dos proyectos del website.

Acabamos de crear dos twigs de lanzamiento, una para cada uno de los dos sitios. Todo se convierte en troncal para cada uno de los sitios de forma normal cuando se trabaja y cuando está "listo para funcionar" lo fusionamos en la twig de lanzamiento para ese sitio. Funciona muy bien, excepto que hoy hemos modificado parte del código compartido y notamos que la twig de publicación lo sacó inmediatamente cuando hicimos una actualización en la twig de publicación. Esto no es lo que queríamos 🙁

Así que cualquier idea de cómo podemos resolver este problema. Usamos elementos externos para SECAR el intercambio del código, pero ¿hay alguna otra manera? Tenga en count que en esta pregunta ( ¿Cómo puedo ramificar en SVN y hacer que se bifurque mi svn: también carpetas externas? ) Mencionan que las externalidades son malas y deberíamos usar un process de compilation diferente, pero sin mencionar lo que debería ser.

Tenemos CruiseControl.net ejecutando nuestras construcciones y estamos ansiosos por get esta tuerca rajada. ¿Alguien tiene alguna idea sobre un mejor process?

Aclamaciones

Pete

ACTUALIZACIÓN: Desde entonces hemos pasado a utilizar Mercurial (horno de Fogcreek) 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, ya que es labeldo y simplemente mantener todo actualizado. Nuestro último método es unir ambos proyectos en un solo repository, incluidos todos los repos compartidos también. Esto nos da un "megaproyecto" que ralentiza el time de clonación (echa un vistazo en SVN) pero lo hacemos tan raramente que las ganancias de no tener que lidiar con sub-repositorys hace que valga la pena. Ahora usamos funciones de conmutación / alternancia en lugar de ramificación, lo que también simplifica enormemente nuestro desarrollo.

Si entiendo correctamente, tiene algo así como la siguiente estructura:

  • Proyecto 1
    • el maletero
      • biblioteca (a través de svn:externals library svn://repo/library )
    • twigs
      • release1
        • biblioteca (a través de svn:externals library svn://repo/library )
      • lanzamiento2
        • biblioteca (a través de svn:externals library svn://repo/library )
  • proyecto2
    • el maletero
      • biblioteca (a través de svn:externals library svn://repo/library )
    • twigs
      • release1
        • biblioteca (a través de svn:externals library svn://repo/library )
  • biblioteca

Supongo que es la configuration svn:externals en / project1 / trunk to / library. Si luego combina la revisión con svn:externals a / project1 / branches / release1 y actualiza esa twig, obtendrá automáticamente la última versión de la biblioteca. Por defecto svn: externals obtendrá la revisión HEAD del enlace.

Puede definir svn:externals para vincular a una revisión específica, como esta: svn:externals -r123 library svn://repo/library . Esto significa que el enlace externo siempre apuntará a esa revisión específica. Para que pueda usar este tipo de enlace svn:externals forma segura en su twig de publicación sin preocuparse de que el código de la biblioteca compartida se actualice alguna vez, a less que cambie manualmente el svn:externals

Probablemente una mejor manera sería usar tags para la biblioteca compartida y un enlace a una label específica. En este caso, obtendrías la siguiente estructura de repository:

  • Proyecto 1
    • el maletero
      • biblioteca (a través de svn:externals library svn://repo/library/tags/version3 )
    • twigs
      • release1
        • biblioteca (a través de svn:externals library svn://repo/library/tags/version1 )
      • lanzamiento2
        • biblioteca (a través de svn:externals library svn://repo/library/tags/version2 )
  • proyecto2
    • el maletero
      • biblioteca (a través de svn:externals library svn://repo/library/tags/version2 )
    • twigs
      • release1
        • biblioteca (a través de svn:externals library svn://repo/library/tags/version1 )
  • biblioteca
    • tags
      • versión 1
      • versión 2
      • versión3

Otherside tiene buenos consejos, pero realmente está usando svn: external como el sistema de gestión de dependencies de un hombre pobre. Está haciendo un anti-patrón hacky algo viable para los disciplinados.

Tienes toda la razón de que svn: externals no es el path.

Una cosa más en la que pensar, si te mantienes en esa ruta, a less que tus tags svn sean atómicas (a través de un enlace precompromiso), querrás especificar la revisión así como la label.

Actualmente estoy sufriendo un shock de concha al haber henetworkingado algunas cosas de .NET, me hace extrañar mucho a maven. Incluso me conformaría con un desastre de ant / hiedra.

Puede consultar https://www.nuget.org/

Puedes hacer svn update --ignore-externals si no quieres que se actualicen los externos.

Sí, usar elementos externos apuntando a una revisión o label específica es el path a seguir. Usted podría encontrar esto simplemente leyendo el manual svn en externos … ¡RFD! también, tiene solo una página de largo … 🙂

http://svnbook.networking-bean.com/en/1.0/ch07s03.html

Estoy creando twigs de liberación / estables copyndo también las externas para que la twig se vuelva completamente independiente del tronco. Externals son svn-copydos usando

svn copy –parent

… a su punto de assembly respectivo. los externos no revisados ​​usan la revisión en la que desea enraizar su twig; los externos revisados ​​usaron su revisión especificada en la copy. svn: las properties externas se deben eliminar en la nueva twig.

Algunos scripts (perl para mí) pueden ayudar a automatizar esto. Hazme ping si necesitas más información sobre esto.