Subversion: ¿de dónde deberían venir los svn: externals?

Estoy a punto de establecer una regla en el trabajo aquí que todas las references svn: externals deben provenir de la label de otro proyecto, nunca desde su troncal o desde cualquiera de sus twigs. ¿Es esta una regla razonable o ves problemas / problemas con este enfoque? Estoy tratando de lograr un entorno de desarrollo estable y me pregunto si esta regla haría el desarrollo más lento o más difícil.

Su preocupación es que un proyecto con "svn: externals" puede cambiar sin ningún compromiso para ese proyecto. Eso es un problema porque es difícil descubrir el cambio de rotura o retroceder a una buena versión.

Entonces sí, exigir que svn: las references externas sean estables es una buena regla. Solo permitir references a tags es una forma de lograr eso. Otra forma es usar la syntax -r para fijar el externo a una revisión fija. Ejemplo del libro de subversión :

third-party / skins -r148 http://svn.example.com/skinproj

Esto también lo protegerá contra los cambios en las tags, una mala práctica que es más común de lo que me gusta.

Dicho esto, todavía hay una compensación entre la estabilidad y la continuous integration . A menudo necesita los cambios y las correcciones de errores en las dependencies externas de todos modos. En ese caso, desea que su server CI le notifique lo más rápidamente posible que algún cambio en las dependencies interrumpe su proyecto, de modo que el problema pueda solucionarse lo antes posible. La mayoría de los serveres de continuous integration tienen soporte para verificar externos.

Por esta razón, creo que está bien mantener los elementos externos en el seguimiento de líneas troncales en la CABEZA troncal de sus dependencies (si tiene un server CI). Simplemente fije sus externos a revisiones fijas cuando etiquete y cuando cree twigs de mantenimiento estables.

Creo que todo se networkinguce a la madurez de las prácticas de desarrollo de software. ¿Tienes processs de gestión de cambios? Generaciones e informes automatizados Etc. Lo más seguro es enlazar con una construcción labelda del proyecto (es decir, lib's, dll's, jar's, etc.).

Si el proyecto externo tiene lanzamientos semanales con correcciones de errores frecuentes, podría ser útil y obstaculizar. Descubrí que, sin una buena política de administración de la configuration, los enlaces a las tags hacen que sea fácil perder actualizaciones críticas. Y, para el momento en que logre "actualizar" esa dependencia, puede haber muchos pequeños cambios que sumen mucho trabajo.

En proyectos relativamente estables, esta es una buena idea. El único problema es que no todos los IDE dejan en claro que un directory de origen es una reference externa. En ese caso, es muy fácil para los desarrolladores registrar cambios en esa label. Por lo que recuerdo, Subversion aún no implementó "solo lectura", aunque he estado usando una versión anterior.

¿Y la decisión de permitir realmente los externos? Se asegura de estar haciéndolo por las razones correctas. A menudo es mejor simplemente realizar el pago desde el lugar original y / o registrar las dependencies en varios lugares. Me han quemado references externas en el pasado. Si vas a ramificar, se convierten en un problema real a less que "congeles" el exterior cuando lo haces.

Pero para responder a su pregunta, tiene mucho sentido tener una location específica donde se coloquen y se mencionen todos los elementos externos. Eso significa que puede controlar el contenido de esa location y la gente sabe que cuando colocan algo allí, se utilizará como un recurso externo y, por lo tanto, dependerá de muchos proyectos.

Depende de cuán estable consideres que sea trunk.

  1. Si tu maletero es algo que siempre está listo para ser lanzado, entonces realmente no quieres que tus elementos externos apunten al maletero.
  2. Si tiene twigs de liberación que solo cambian al fusionarse en revisiones desde el tronco, entonces realmente no quiere que sus externos señalen al tronco.
  3. Si por alguna razón quieres una revisión en el tronco que diga "ahora estoy usando esta versión de este externo", tomando así control de todos los cambios en tu código de proyecto, entonces no quieres que tus externos apunten al tronco.

Sin embargo, está bien que un desarrollador cambie las copys de trabajo de sus externos a un tronco. También está bien apuntar al tronco dentro de una twig de desarrollo. Puede estar bien apuntar a trunk antes de la primera versión estable de un proyecto.

Mi opinión personal es tratar el baúl con mucho cuidado, ya que tiene un significado especial para mí: es la historia completa del proyecto. Todo lo que se libera debe pasar por el tronco, por definición. Si puede cambiar la troncal sin tener una revisión registrada contra el cambio (que es efectivamente lo que sucede si apunta a una troncal externa), ha perdido el control sobre cuándo lanzar esa revisión, y cuándo incorpora esa revisión en su proyecto .

Recordando cambiar todas sus references a revisiones específicas cuando se ramifica desde el tronco puede ser una testing. Hudson puede hacer las cosas más visibles con su soporte de labeldo, pero poco más ayuda.

Señalar al tronco también puede conducir al problema de la " biblioteca intocable ".

Cuando se trata de CI, no hay ninguna razón por la cual no se puede hacer IC en todos los componentes, así como en los proyectos integrados finales. Al elegir cuándo fusionarse en la última biblioteca, elige cuándo desea realizar el trabajo de integración.

Sin embargo, sería bueno tener algún mecanismo que diga "Tu proyecto está usando una biblioteca desactualizada, la última versión es X". Esto no es posible en este momento.

Además, si ha nested elementos externos, presionar un cambio desde una biblioteca base a través de 5 capas de references hasta llegar al proyecto principal es una molestia.