¿La mejor manera de estructurar un repositorio en Subversion para proyectos de Visual Studio?

Question

Tengo algunos proyectos C# .dll que son comunes para muchas aplicaciones. Actualmente, tengo un gran repositorio. Tengo cada DLL almacenado como un proyecto separado dentro del repositorio y cada proyecto de aplicación almacenado como un proyecto dentro del mismo repositorio.

Recientemente cambié a Subversion para el control de código fuente y me temo que no hice un buen trabajo de estructuración del repositorio. Me gustaría escuchar lo que otros están haciendo.

Answer 1

usando la rama/tronco/tag la estructura del repositorio es bastante estándar, pero si yo soy tu Al entenderlo correctamente, su problema es que tiene un conjunto de proyectos dll comunes que se utilizan en múltiples proyectos. Esto definitivamente puede ser difícil de manejar.

El escenario típico aquí es que tiene una biblioteca de clases llamada Common.Helpers que tiene un código que es común a todas sus aplicaciones.

Digamos que estoy iniciando una nueva aplicación llamada StackOverflow.Web que debe hacer referencia a Common.Helpers.

Normalmente lo que haría sería crear un nuevo archivo de solución y agregar un nuevo proyecto llamado Stackoverflow.Web y agregar el proyecto Common.Helpers existente y luego hacer referencia al nuevo proyecto Stackoverflow.Web.

Lo que generalmente trato de hacer es crear un repositorio para el proyecto Common.Helpers y luego en subversión hacer referencia a él como external. De esta forma, puede mantener el código bajo control de origen en una única ubicación, pero aún así usarlo por separado en múltiples proyectos.

Answer 2

repositorios de Subversion son típicos subdividen en:

branch/ 
tags/ 
trunk/ 

Se podría o bien colocar todos los proyectos DLL y aplicaciones en el tronco y luego usar rama y etiquetas para todos ellos como sea necesario también:

branch/ 
tags/ 
trunk/ 
    project1/ 
    project2/ 

O bien, puede crear carpetas para cada proyecto en la raíz y luego coloque la rama común, las etiquetas y las carpetas de troncales dentro de ellos.

project1/ 
    branch/ 
    tags/ 
    trunk/ 

project2/ 
    branch/ 
    tags/ 
    trunk/ 

Tenga en cuenta que esta práctica es simplemente convencional y nada en SVN requiere (o realmente promueve) hacerlo exactamente de esta manera. Sin embargo, todos están acostumbrados. Entonces, harías un favor a la gente para que lo aceptes.

Para más detalles, la troncal es donde tendrá lugar su desarrollo principal. Cuando desee marcar una revisión en particular (por ejemplo, una versión de lanzamiento), simplemente svncopie el proyecto en el directorio de etiquetas. Además, solo copie el código en el directorio de la rama cuando desee hacer algo dramático o prolongado y no quiera obstaculizar el progreso en el troncal. Más tarde se puede SVNfusión su rama de nuevo en el tronco cuando está listo para la acción!

Si desea corregir contratiempos en su repositorio Subverion actual, entonces sólo tiene que utilizar SVNmovimiento reubicarlos. A diferencia del proceso de eliminación y adición de CVS, move retendrá el historial de versiones para la nueva ubicación.

Answer 3

si sus proyectos secundarios se pueden lanzar en diferentes versiones (como controles, elementos web, ect ...), Entonces puede tener sentido para construir su estructura como esta:

Solución
Proyecto 1

• Branch
• Etiquetas
• tronco

Proyecto 2

• Branch
• Etiquetas
• tronco

De esta manera se puede gestionar cada versión proyecto de forma independiente.

De lo contrario la estructura más común es:

• Branch
• Etiquetas
• tronco
• Docs (Opcional)

Answer 4

Guardo todo en el repositorio para facilitar a los desarrolladores (o reconstrucciones) la salida desde SVN y luego ejecutar una construcción (con todos los ensamblajes necesarios en rutas relativas). Si tiene varios proyectos que deberían estar separados, esto también alentaría al equipo de sus componentes compartidos a entregar montajes de alta calidad. Esto podría seguir una mentalidad de lanzamiento normal a producción donde el ensamblado compartido se actualizaría en sus proyectos posteriores. Este es un Software Value Chain, muy natural a costa de un poco de espacio en disco.

JP Boodhoo tiene a great series sobre el tema de compilaciones automatizadas, estructura de carpetas VS, y poner a los desarrolladores en funcionamiento rápidamente.

Answer 5

Gracias a todos los que respondieron. lomaxx, pasé la mañana investigando el uso de la función externa y parece que este es el camino a seguir. No estaba al tanto, probablemente porque no es exactamente prominente en Tortuga.

Answer 6

Si desea utilizar el seguimiento de fusión de Subversion 1.5 en más de un proyecto al mismo tiempo, debe usar un solo árbol sin elementos externos.

Una fusión con seguimiento es (como una confirmación) siempre sobre un directorio y sus secundarios.

La misma regla se aplica a las confirmaciones atómicas. (Funciona solo estable en una sola copia de trabajo. Podría funcionar en algunos otros casos específicos pero ese comportamiento no está garantizado)