¿Cómo lidiar con los submódulos de Git en las soluciones de Visual Studio con diferente diseño?

Question

Desarrollamos con Visual Studio 2010 (en C#) y migramos hace un tiempo de SVN a GIT. Ahora intentamos dividir nuestro repositorio (que es bastante grande - ~ 30.000 archivos) en muchos repositorios de git, uno para cada solución. Las soluciones comparten algunos proyectos, en su mayoría bibliotecas que desarrollamos internamente y que nos gusta agregar desde todas las soluciones.

Los nuevos repositorios tienen un diseño plano. Un subdirectorio para cada proyecto (los proyectos compartidos son submódulos). En el gran repo viejo, los proyectos están en una estructura de árbol.

El problema ocurre con referencias externas en los submódulos. En los repositorios nuevos, la ruta a un proyecto referenciado puede ser "...... libs \ someproject", mientras que en el nuevo diseño la ruta correcta sería ".. \ someproject".

Ya hemos tenido algunas guerras de edición relacionadas con esto y no estamos interesados ​​en más.

soluciones a medias que se me ocurrieron:

• uso "trayectorias de referencia" en ... csproj.user y excluir este archivo de control de versiones (tiene que ser hecho de nuevo para cada desarrollador y después de cada limpieza reopsitory)

• ramas de uso para cada situación y tratar de enseñar a todos donde commit "reales" deben ir y dónde "entorno de cambio" confirmaciones deben ir (submódulos ya no son el concepto más simple ...)

• binarios de inserción en lugar de los submódulos (¿pero qué hay de desarrollar cambios en los submódulos? ¿qué pasa con las diferentes versiones de log4net?)

¿Alguien sabe de una solución sensata?

Answer 1

Puesto que usted está solicitando una solución sensata, sólo puedo aconsejarle que mirar en la creación de su propio servicio de NuGet (mirar http://www.MyGet.org para la inspiración)

http://nuget.codeplex.com/

Answer 2

Utilice un submódulo para albergar todas las "bibliotecas comunes". Solo un nivel. Pero debe mover las bibliotecas comunes como servicios con contratos bien definidos. De esta forma, puede lanzar incrementalmente nuevas versiones sin tiempo de inactividad. De esta forma, solo tienes un submódulo en cada uno de los contratos. Estas podrían ser interfaces o mensajes.

Answer 3

Así que si he entendido bien, el problema es con Visual Studio y no con Git? Si ese es el caso, use la estructura de árbol anterior que funcionaba con Visual Studio. Haga que sus submódulos estructuran también una estructura de árbol. Entonces, la parte superior del árbol sería un superrepo cuyos submódulos (las ramas) tendrían submódulos propios, hasta que llegue a las hojas de su árbol. Al principio sería difícil establecerlo, pero debería funcionar.

Answer 4

IF Si va por la ruta de la gestión de paquetes, considere OpenWrap. Sin embargo, incrustar los artefactos de gestión de paquetes en el código fuente es una mala idea. Puede usar estas herramientas para actualizar lo que realmente está almacenado en los submódulos, pero no confíe en ellos en el momento de la compilación. Espere que los binarios estén allí desde el punto de vista de sus scripts de compilación.

Answer 5

Tengo un problema similar con VS 2013.

Quiero usar git-svn en lugar de SVN directamente. SVN tiene un gigantesco conjunto de directorios. No pude crear un solo repositorio git que contuviera toda nuestra carpeta troncal. Git-always salió con un error y el repositorio estaba dañado. Trabajé todo el problema haciendo la siguiente manera:

1. Usando git-svn, que clona el subconjunto de carpetas fuera SVN/tronco que necesitaba mediante la creación de un repositorio git-por carpeta.
2. Creé un repositorio parent git local que contiene todas mis carpetas git-svn-cloned.
3. Cada git-repositorio se agregó como un submódulo al padre git-repository.

El problema con Visual Studio es que no reconoce los proyectos múltiples fuera del proyecto principal donde abrí la solución. Esta solución se encuentra en una carpeta que contiene los únicos archivos reconocidos por Visual Studio como bajo el control git-source.

Intenté configurar las preferencias de git para usar el directorio principal de nivel superior como la ubicación de git-repostitory sin notar ninguna diferencia.