SVN Repository Structure - ¿Por qué es esto mejor?

Question

Me han dicho que la mayoría de tiendas de desarrollo tienen la siguiente estructura o al menos cerca de esto:

• Principal de
  • carpetas de proyecto debajo
  • Cada carpeta de proyecto tiene un tronco, ramas, y las etiquetas de la carpeta

manera:

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
     ... 

¿Por qué es esto mejor o mejor? ¿Qué sucede o qué angustias te has encontrado si lo hicieras de otra manera?

Answer 1

Esta forma de organizar el repositorio:

ReponsitoryMain 
    Project1 
     branches 
     trunk 
     tags 
    Project2 
    ... 

es mejor cuando sus proyectos no dependen de que conectado/el uno del otro. A la inversa, es más fácil versionar todo el conjunto de proyectos. Por lo tanto, si a menudo publica/empaqueta Project1 y Project2 juntos, es mejor que compartan la misma rama.

Si, por otro lado, su proyecto está muy desacoplado y tiene equipos totalmente diferentes trabajando en ellos, entonces no sería necesario que revisen todos juntos la mayor parte del tiempo, por lo que podría usar el método anterior .

Answer 2

Eso es lo que tenemos. Funciona y eso es suficiente por ahora (porque nunca sabemos lo que traerá el futuro) No tenemos razones convincentes para gastar un tiempo valioso (y dinero) para encontrar una estructura posiblemente más óptima.

M.

Answer 3

La mayoría de la gente hace esto porque está recomendado por la Subversion book.

He aquí una buena explicación por parte del director del proyecto CollabNet Subversion:

http://blogs.collab.net/subversion/2007/04/subversion_repo/

Answer 4

mantenemos un repositorio separado para cada proyecto.

Si bien esto no le permite copiar y mantener los archivos del historial de versiones de un proyecto a otro, le permite archivar un repositorio completo cuando termina un proyecto.

Answer 5

Las ramas y etiquetas de troncos funcionan de la misma manera. Cómo los usa depende de usted.

He estado utilizando esta estructura durante años y todavía tengo que encontrar un momento en que la estructura no se adaptó a lo que tenía que hacer.

Answer 6

La estructura del repositorio depende de sus necesidades. Si sus proyectos están completamente separados (sin dependencias entre ellos), esta estructura de repositorio "simple" está bien. Si tiene dependencias en su proyecto (por ejemplo, algunas "herramientas" globales-bibliotecas, código compartido) que debe utilizar una estructura diferente como:

trunk 
    prj_a 
    prj_b 
tags 
    <YOUR_TAGNAME> 
     prj_a 
     prj_b 
branches 
    <YOUR_BRANCHNAME> 
    prj_a 
    prj_b 

o cualquier otra cosa que hace más sentido para su proceso.

En la estructura simple con tronco/etiquetas/ramas locales no es posible (al menos de forma limpia) etiquetar proyectos múltiples, si tiene dependencias entre ellos.

También el enfoque de "múltiples repositorios" que se propone a menudo no cubrirá este vacío ya que está condenado a múltiples revisiones o etiquetas en múltiples repositorios.

El principal problema es que SVN tiene NO admite recursos compartidos y los etiqueta/ramifica.

Si piensa en la estructura de su Repositorio, debe preguntarse en qué proceso desea compartir sus bibliotecas de códigos.

Answer 7

Ok, voy a ser un poco más predilecto y me siento firmemente del lado de tener un baúl, etiquetas & ramas para cada proyecto.

La principal alternativa es tener un solo tronco, etiquetas & ramas con todos los proyectos debajo. Sin embargo, esto conduce a una serie de problemas, uno de los cuales es significativo y detallaré aquí:

Principalmente allana el camino a la biblioteca intocable, donde todos tienen miedo de tocar una biblioteca en particular porque cualquier cambio puede romperse algo sutil en algún proyecto aleatorio. La causa de esto es que, debido a que no hay separación entre proyectos, cualquiera puede cambiar efectivamente el código en su proyecto sin que usted sea capaz de detectarlo o controlarlo.

Lo que sucede es que un día que revisa su proyecto y lo construye, al día siguiente lo comprueba y falla, pero ha realizado sin cambios en su proyecto. Lo que sucedió es que alguien ha cambiado una biblioteca en la que usted dependía. En una estructura grande con muchas dependencias, no es realista que un desarrollador pruebe los cambios de su biblioteca en contra de cada proyecto, especialmente si tienen que realizar cambios importantes. Lo que necesita en su proyecto es una referencia a una versión específica de la biblioteca. De esta forma, la biblioteca solo se actualiza cuando cambia la referencia a la última versión.

Este tipo de referencia tiene 3 efectos: 1 su proyecto está aislado de cambios aleatorios de desarrollo intermedio en la biblioteca. 2 obtendrá una revisión en su proyecto que le dice que "ahora estoy usando esta versión de la biblioteca". 3. Puede controlar cuándo realiza los cambios en su proyecto para dar cuenta de cualquier cambio en la biblioteca.

Existen otros problemas por los que puedo pasar si esto no es suficiente.

Answer 8

En sistemas como CVS, no tenía "directorios" separados. Acabas de etiquetar y ramificar.

Sin embargo, SVN se basa más en la idea de instantáneas y, por lo tanto, las "copias" de las cosas se realizan de manera muy eficiente. En lugar de etiquetar o marcar versiones especiales (o alternativas) de un proyecto, es más fácil (y más eficiente) hacer una copia con nombre de él.

Answer 9

En mi tienda, tenemos algo como esto:

RepositoryMain 
    Trunk 
    proj 1 
    proj 2 
    .. 
    Dev 
    Team1 
     proj 1 
     proj 2 
    Team2 
     proj 1 
     proj 2 
    ... 

No sé cómo esto se acumula hasta la mayoría de los lugares, pero parece que funciona bastante bien

Todos los equipos de desarrollo pueden trabajar por separado en sus propios proyectos, fusionándose desde el tronco hasta su proyecto cuando están comenzando el desarrollo/mejora, y luego volviendo a fusionarse con el tronco una vez que hayan finalizado.

Answer 10

Gracias por la discusión aquí, fui a través de este y project-structure-for-product-with-different-versions

link2

link3

link4

pude ver terminologías son confusas. Proyectos, Aplicaciones, para correlacionar correctamente

gustaría repetir las cosas de arriba con un poco clara exp digamos que hacemos solución para un cliente ABC solución es la compra de entradas/Aplicación servicio de asistencia para los clientes de ABC Realiza consultas

permite decir applicationName es OneDeskApplication. Esta aplicación consiste de WebUI, bibliotecas compartidas, herramientas de generación

podemos diseñar el SVN como esto

XSoftware.com/ABC - Repositorio / tronco/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp ramas/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp tags/ OneDeskDocs OneDeskMasterBuild