Prácticas recomendadas para las dependencias de control de origen

Question

¿Cómo se maneja la configuración de control de origen de un proyecto no compilado que tiene dependencia de un marco o biblioteca independiente? Por ejemplo, el Proyecto A usa el Marco B. ¿El Proyecto A también debe incluir el código del Marco B en su repositorio? ¿Hay alguna manera de que se incluya automáticamente desde un repositorio diferente o tendría que actualizarlo manualmente? ¿Cuáles son los enfoques generales usualmente tomados para este escenario? Supongamos que controlo los repositorios para el Proyecto A y el Marco B y que el código fuente para ambos no está compilado.

Cualquier recurso o sugerencia sería muy apreciada. Actualmente estoy usando Subversion (en un nivel muy básico), pero me gustaría cambiar a Mercurial para que pueda probar Kiln con Fogbugz.

Editar: En Mercurial, ¿usaría los repositorios principales para esta función?

Answer 1

Si desea usar subversion y necesita incluir código de un repositorio diferente, Subversion Externals podría ser una opción.

Sin embargo, si se trata de un código compilable, podría ser mejor configurar un proceso de compilación que simplemente obtenga los archivos binarios necesarios. Las herramientas de compilación como Maven pueden ayudarlo con eso.

Answer 2

La mayoría de las veces trato de incluir todo lo necesario para construir el proyecto en subversión. Esto está usando C# y Visual Studio, por lo que la mayoría de mis dependencias son dlls. Las convenciones pueden variar un poco en otros entornos.

Esto es por lo general la forma en que estaba a cabo un nuevo proyecto:

• ref
  • SomeOpenSourceProject.dll
  • SomePurchasedComponent.dll
• MyProjectA
  • MyProjectA. cspro j (referencias .. \ ref \ SomeOpenSourceProject.dll)
• MyProjectB
• MyWeb (referencias .. \ ref \ SomePurchasedComponent.dll)
• MyApplication.sln

De esta forma, puede ser revisado y creado por un nuevo desarrollador sin mucha molestia. En el pasado solían usar un recurso compartido de red para las DLL, pero eso se volvió molesto ya que los diferentes proyectos usaban versiones diferentes y si querías volver a la subversión o rama o cualquier otra cosa, era difícil hacer un seguimiento. Esta estructura resolvió esos problemas muy bien.

Answer 3

Si B es un proyecto de código abierto, y desea compilarlo con A, le sugiero que pruebe la técnica vendor drop. De esta forma puedes conservar tu propio parche.

Si B es el código propietario de su empresa, y no desea compilarlo, sería mucho más fácil simplemente copiar los binarios compilados en el repositorio A '.

Answer 4

hago algo muy similar a David Hogue, excepto que se parezca a esto:

- lib (anything used IN the software) 
    - purchased_component.dll 
    - internal_library.dll 
    - icon_set 
     - icon1.ico... 
- tools (anything used to BUILD the software) 
    - nunit.framework.dll 
    - settings.stylecop 
    - settings.fxcop 
- src (the software itself) 
    - myapp.sln 

La mayor parte de la inspiración para esta configuración vinieron de tree surgeon (bastante anticuada ahora, sin embargo)