Estructura de proyectos en control de versiones – específico de .NET

Esta publicación es similar a esta pregunta previa. Realmente quiero configurar mi repository SVN en formatting TTB, pero cuando creo un proyecto en Visual Studio 2008 (ASP.NET/VB.NET), la estructura creada tiende a ser incompatible cuando se considera el file de solución, los files de proyecto, las carpetas para proyectos, proyectos múltiples en soluciones, etc. ¿Alguien tiene un script o procedimiento para tomar un proyecto ASP.NET recién creado y moverlo a un formatting TTB de la forma más sencilla posible?


Déjame ser más específico. Supongamos que tengo un proyecto que estoy creando llamado StackOverflowIsAwesome. Puedo poner eso en mi estructura de carpetas local (digamos que es c: \ working). Cuando lo creo, VS crea c: \ working \ StackOverflowIsAwesome y un montón de subcarpetas (bin, app_data, etc.). Pero quiero que mi estructura de repository se vea como …

 StackOverflowIsAwesome
     /el maletero
         /compartimiento
         /datos de aplicación
     / tags
     / twigs

Entonces, ¿existe una manera clara de hacer esto de manera consistente o necesito recurrir a mover y modificar constantemente files y carpetas para que esto funcione?

Fuimos con un enfoque muy simplist:

Estructura del file:

  • Carpeta de solución (contiene file de solución, scripts de compilation, ¿quizás más?)
    • Carpeta de proyecto
    • Carpeta del proyecto 2
    • Referencias (contiene sets compartidos para la solución).

Luego, simplemente verificamos los contenidos de la carpeta de la solución completa en nuestro repository. Usamos un repository para cada solución. No estoy seguro de si esta es la forma óptima de organizar la solución, pero funciona para nosotros.

Además, ramificamos al más alto nivel, no por proyecto.

De otra manera:

StackOverflowIsAwesome /trunk /database /datafiles /documents /build /installer /lib /External_DAL (external that points to shanetworking library) /utilities /vendor /src /StackOverFlowIsAwesome /StackOverFlowIsAwesome.csprj /bin /... /StackOverFlowIsAwesomeTests /StackOverFlowIsAwesomeTests.csprj /bin /... /branches /tags 

Esto sería para cada proyecto. Dado que estamos usando un script de compilation, no necesitamos almacenar nuestro file de solución en SVN.

Si su TTB es común en lugar de por proyecto, no hay problema con eso. ¿O me estoy perdiendo algo?

Puedes ver esta publicación anterior o este proyecto . El proyecto crea una estructura de tree de desarrollo .NET (requiere .NET 3.5).

Cuando se trata de proyectos múltiples que conforman una solución de Visual Studio es difícil decidir cómo estructurar las cosas correctamente.

Un aspecto crítico que tendrá que hacer con su estructura es facilitar la recuperación de todos los files para una versión en particular. Es importante hacer esto lo más fácil posible. En subversión, copyr una carpeta raíz a las twigs de tags es más fácil que recordar repetir la misma operación para proyectos X.

Poder trabajar durante períodos prolongados fuera del tronco principal también es importante. Deberás considerar eso también.

Puede encontrar que su software tiene una serie de componentes que se agrupan de forma natural. Podrías hacer algo como esto

 /tag /core_library /branch /main /business_logic /branch /main /report_library /branch /main /my_ui /branch /main 

No hay una respuesta fácil. Lo que haces realmente depende de tu proyecto específico. Si todo sigue saliendo como un lío ennetworkingado, entonces tal vez necesites ver cómo está diseñado tu proyecto y ver si eso puede cambiarse para mejorar la comprensión.

Para proyectos más grandes usualmente usamos este formatting aquí:

 /Project /trunk /lib/ # Binary imports here (not in svn) /src # Solution file here /Libraries # Library assemblies here /StackOverflowIsAwesome.Common /Products # Delivenetworking products here /StackOverflowIsAwesome.Site /Projects # internal assemblies here /StackOverflowIsAwesome.Tests /branches /1.x /tags /StackOverflowIsAwesome-1.0 

Según el proyecto real, los files no fuente (documentos, etc.) tienen un directory debajo de la raíz del tronco y los resources de desarrollo adicionales están bajo src.

Los proyectos independientes bajo están bajo su propia raíz / Proyecto, pero en el mismo repository.

Lo hago de esta manera:

  1. Crea el proyecto en VS
  2. Importe todo en la carpeta del proyecto a repos / projectname / trunk
  3. Agregue las carpetas de repositorys / sucursales y repositorys / tags

Eso me da una estructura de repository como:

 projectname / trunk /bin /obj /Properties projectname.sln /tags /branches 

Y puedo dejar todos los files en sus lugares pnetworkingeterminados en el sistema de files.