svn - subir - ¿La mejor forma de estructurar un repositorio en Subversion para proyectos de Visual Studio?
subir proyecto a svn (6)
El uso de la estructura del repositorio branch / trunk / tag es bastante estándar, pero si lo entiendo bien, 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.
Entonces, 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 necesita hacer referencia a Common.Helpers.
Por lo general, 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 un 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.
Tengo algunos proyectos C # .dll que son comunes para muchas aplicaciones. Actualmente, tengo un gran repositorio. Tengo cada archivo 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 estructurar el repositorio. Me gustaría escuchar lo que otros están haciendo.
Gracias a todos los que contestaron. 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.
Guardo todo en el repositorio para facilitar a los desarrolladores (o reconstruir devboxes) el check-out 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. Esta es una cadena de valor de software muy natural , a costa de un poco de espacio en disco.
JP Boodhoo tiene una gran serie sobre el tema de compilaciones automáticas, estructura de carpetas VS y cómo poner a los desarrolladores en funcionamiento rápidamente.
Los repositorios de Subversion son típicamente subdivididos en:
branch/
tags/
trunk/
Debería colocar todos sus proyectos DLL y de aplicaciones en el tronco y luego usar branch y tags para todos ellos según sea necesario también:
branch/
tags/
trunk/
project1/
project2/
Alternativamente, puede crear carpetas para cada proyecto en la raíz y luego colocar la rama común, las etiquetas y las carpetas troncales dentro de ellas.
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 mayor detalle, el tronco es donde tendrá lugar su desarrollo principal. Cuando desee marcar una revisión en particular (por ejemplo, una versión de lanzamiento), simplemente svn copie el proyecto en el directorio de etiquetas. Además, solo copie el código en el directorio de la bifurcación cuando desee hacer algo dramático o prolongado y no quiera obstaculizar el progreso en la troncal . Más tarde puede svn fusionar su rama de nuevo en el tronco cuando esté listo para la acción.
Si desea corregir percances en su repositorio Subverion actual, simplemente use svn move para reubicarlos. A diferencia del proceso de eliminación y agregación de CVS , move retendrá el historial de versiones para la nueva ubicación.
Si sus subproyectos se pueden lanzar en diferentes versiones (como controles, elementos web, etc.), entonces puede tener sentido construir su estructura de esta manera:
Solución
Proyecto 1
- Rama
- Etiquetas
- El maletero
Proyecto 2
- Rama
- Etiquetas
- El maletero
De esta forma, puede administrar cada lanzamiento de proyecto de forma independiente.
De lo contrario, la estructura más común es:
- Rama
- Etiquetas
- El maletero
- Documentos (opcionales)
Si desea utilizar el seguimiento de fusión de Subversion 1.5 en más de un proyecto al mismo tiempo, debe usar un único árbol sin elementos externos.
Una fusión con seguimiento es (como una confirmación) siempre sobre un directorio y sus hijos.
La misma regla se aplica a las confirmaciones atómicas. (Funciona solo de forma estable en una sola copia de trabajo. Podría funcionar en algunos otros casos específicos, pero ese comportamiento no está garantizado)