Estructura de directorios de trabajo para el repositorio SVN Visual Studio

Question

Acabo de presentar SVN en nuestra empresa para nuestros proyectos de Visual Studio y creé un repositorio que se parece a esto ("solución" es una solución Visual Studio que contiene proyectos 1..n):

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

Ahora, tengo dos opciones para estructurar los directorios de trabajo locales:

Opción a: Deje la caja de usuario cada solución por separado utilizando AnkhSVN, dando lugar a una estructura como esta:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/solution3/projectD/... 
/solution4/projectE/... 
      /projectF/... 

o esto, si le digo al usuario crear manualmente un subdirectorio cliente X:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/customerX/solution3/projectD/... 
/customerX/solution4/projectE/... 
        /projectF/... 

Ventaja: El usuario puede obtener sólo las soluciones que realmente necesita. Desventaja: cada solución necesita ser revisada/actualizada por separado.

Opción B: Dile al usuario a la comprobación del repositorio completo utilizando TortoiseSVN, dando lugar a una estructura que es exactamente el mismo que el repositorio:

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

Ventaja: Es muy fácil "SVN actualizar todo ". Desventaja: el usuario también tiene una copia local de todas las ramas y etiquetas.

---

PREGUNTA: Dado que algunos proyectos son compartidos entre las soluciones (digamos, por ejemplo, que ProjectA es una biblioteca que también es utilizado por solution3), tenemos que arreglar una estructura de directorios, para asegurarse de que las rutas relativas en la solución, los archivos son correctos. ¿Qué opción recomienda y por qué?

---

EDIT: Gracias por todas sus respuestas excelentes, en particular para mencionar svn:externals y para destacar la importancia de un buen diseño del repositorio. Terminé actualizar mi repositorio estructura:

/trunk/solution1/projectA/... 
       /projectB/... 
     /solution2/projectC/... 
     /customerX/solution3/projectD/... 
          -svn:external to projectA 
       /solution4/projectE/... 
          /projectF/... 

que asegura que un desarrollador que trabaja en solution3 sólo necesidades de revisar solution3 (y no solución1) y la solución se puede comprobar a cabo en cualquier directorio , es decir, el directorio de trabajo no necesita una estructura fija.

Answer 1

Jeje, esto probablemente no es muy útil, pero ... ninguno.:)

Tendría trunk en el nivel más alto, con los proyectos y soluciones organizados debajo de ese uno al lado del otro en una estructura plana. Luego utilizaría la propiedad svn:externals en los directorios de la solución para incorporar los proyectos adecuados a la ubicación correcta en la copia de trabajo de cada desarrollador.

La razón por la que organizaría las cosas de esta manera es que le da los beneficios tanto de su opción A como de su opción B. Por lo tanto, si los desarrolladores solo desean ver una solución única, pueden hacerlo. Del mismo modo, también pueden consultar todo el enlace si prefieren hacerlo en su lugar (y pueden hacerlo sin recibir etiquetas y ramas).

Además, este enfoque de tener un solo tronco hace que sea mucho más fácil etiquetar o bifurcar el repositorio completo, si alguna vez necesita hacerlo.

Answer 2

Por lo que vale la pena, utilizamos la opción B.

También utilizar Tortoise SVN en lugar de Ankh SVN porque tenemos un poco mejor flexibilidad y la estructura de nuestro repositorio si no está ligada a la misma estructura de directorios que Visual Studio espera.

Al principio me opuse con vehemencia a esto porque me gustaba la integración IDE que tenía con TFS, pero después de trabajar con ella por unos pocos días, me dijeron que el intercambio de una mayor flexibilidad es miles de veces más importante que la integración con el IDE.

Editar - Añadido

Es también digno de mención que antes de cambiar a nuestros procesos actuales, estudiamos exactamente cómo queríamos diseñar TODO nuestro control de origen. Nos tomó varias semanas planificarlo exactamente, analizarlo hasta la muerte antes de realizar el cambio, pero dio resultado con facilidad de uso y mantenimiento.

Tenemos una estructura general como la siguiente:

\ Aplicaciones Web interno Aplicaciones

\ Internet Web

\ Windows Forms corporativos Aplicaciones

\ Viudas Corporativos Servicios

\ Ubicación al por menor Aplicaciones WinForms

\ servicios de localización al por menor

\ compartido

\ archivos entre plataformas solución.

Cada una de las carpetas principales contiene muchos proyectos y soluciones diferentes. Cada uno tiene sus propias ramas, etiquetas y troncos. Así, por ejemplo, si tenemos un buscador de internet tienda, que podría estar en

\Internet\<our company name>.com\Store Finder\Trunk 

La parte importante de esto es la compartida, ya que este contiene código que se utiliza en todas las otras ramas. El motivo por el que tener una integración IDE no nos funciona es que necesitaríamos una solución a nivel de raíz para lograr esto. En cambio, tenemos nuestros archivos Sln cuando corresponde y, dado que todos tenemos una copia completa del repositorio, podemos asegurarnos de que las rutas relativas a los proyectos en el directorio \ Shared sean las mismas en todas las PC del desarrollador.

Proporcioné lo anterior, no para decirte cómo estructurar tu código, sino solo para darte ideas y enfatizar lo importante que es planificar a fondo antes de continuar.

Tiene que dedicar un tiempo a hacer preguntas como "Si lo extiendo como Y, ¿podré hacer X?". Su situación será única para su equipo y compañía.

Answer 3

Opción A: no quiere tirar de todo el repositorio (todas las etiquetas y ramas) cada vez y alentará a los usuarios a pensar en todo el repositorio como una entidad única que no es realmente - quieres que piensen en términos de soluciones y de etiquetado/ramificación en ese contexto.

Dirige proyectos compartidos al hacer referencia a ellos como externos en la "raíz" de las soluciones apropiadas. Esto significará que puede hacer que el mismo proyecto aparezca varias veces en su HDD, pero eso es manejable.

Hay una pequeñísima poco más sobre el tema aquí: HowTo: Reference external SLN files with TeamCity

Answer 4

Creo firmemente que la solución de Phil Booths para usar una estructura de directorio plana y usar la propiedad svn:externals incluye proyectos compartidos.

La razón principal es que esto le da la libertad de desacoplar cómo se actualizan los diferentes proyectos de clientes que utilizan un proyecto compartido, como una biblioteca. Con la estructura propuesta, solo hay una copia del proyecto de biblioteca compartida utilizada por todos los demás proyectos del cliente: por lo tanto, todos los proyectos que utilizan el proyecto compartido deben ver la misma versión. Esto no siempre es deseable.

A veces, los cambios en una biblioteca compartida requerirán los cambios correspondientes en el código del cliente utilizando esa biblioteca. Con su estructura propuesta, tal cambio requeriría que actualice todos los proyectos del cliente de la biblioteca de una vez, o viva con el hecho de que muchos de los proyectos del cliente podrían estar rotos.

El uso de svn:externals para cada proyecto de cliente utilizando una biblioteca, significa que cada uno de los clientes tendrá su propia copia de la biblioteca en una copia de trabajo (pero el espacio en disco es barato). Sin embargo, todavía hay una copia del proyecto de la biblioteca en el repositorio (los proyectos del cliente solo refirieren una versión diferente del mismo. Por lo tanto, un proyecto de cliente particular puede continuar utilizando la versión anterior de la biblioteca compartida, o puede actualizarse (por la actualización de la propiedad svn:externals) para utilizar una versión más reciente

En resumen:.

En el diseño propuesto:. cometer un cambio en un proyecto de biblioteca cambios inmediatos todos los proyectos que utilizan la biblioteca todos los proyectos de los clientes consiguen cambios a la biblioteca, ya sea que los quieran o no.

Con svn:externals, realizar un cambio en un proyecto de biblioteca solo afecta la libr ario proyecto solo. Cada proyecto de cliente requiere una confirmación adicional para actualizar la propiedad svn:externals para hacer referencia a la versión más nueva de la biblioteca (que puede comprometerse junto con los cambios de correspondencia en el código del proyecto del cliente). Todos los proyectos de los clientes pueden tener actualizaciones para la biblioteca, pero solo los obtienen cuando los solicitan explícitamente.