Estructura de carpetas para muchos proyectos en un repositorio SVN?

43

Tiene dos opciones para esto. El que ya se ha mencionado, y que es tener un tronco para cada proyecto (opción 1):

https://simucal-projects.googlecode.com/svn/projectA/trunk/ 
https://simucal-projects.googlecode.com/svn/projectA/tags/ 
https://simucal-projects.googlecode.com/svn/projectA/branches/ 

https://simucal-projects.googlecode.com/svn/projectB/trunk/ 
https://simucal-projects.googlecode.com/svn/projectB/tags/ 
https://simucal-projects.googlecode.com/svn/projectB/branches/

Opción 2 sería tener un solo tronco con cada proyecto es una subcarpeta en el tronco:

https://simucal-projects.googlecode.com/svn/trunk/projectA/ 
https://simucal-projects.googlecode.com/svn/tags/projectA/ 
https://simucal-projects.googlecode.com/svn/branches/projectA/ 

https://simucal-projects.googlecode.com/svn/trunk/projectB/ 
https://simucal-projects.googlecode.com/svn/tags/projectB/ 
https://simucal-projects.googlecode.com/svn/branches/projectB/

La ventaja de la opción 1 es que puede bifurcar y etiquetar cada proyecto de forma independiente. Esto es deseable si necesita implementar cada proyecto por separado.

La opción 2 es deseable si todos los proyectos se implementan juntos. Esto se debe a que solo debe etiquetar el repositorio una vez durante la implementación.

Dado que está utilizando Subversion para proyectos escolares, debe preguntarse si alguna vez necesitará etiquetar su trabajo. También puede preguntarse si alguna vez necesita crear ramas (es probable que desee si desea experimentar un poco). También deberá preguntarse si está contento de ramificar TODO su trabajo como uno solo, de si prefiere la flexibilidad de ramificar cada proyecto de forma independiente.

La regla de oro que yo siempre sigo: conectar todo lo que desplegamos juntos.

(Por cierto - puede tener muchos troncos en el mismo repositorio - esto es casi equivalente a tener un tronco en múltiples repositorios, excepto que cada repositorio mantiene su propio contador de revisión y que no puede fusionar entre repositorios.)

Fuente

2009-02-21 20:47:32 Trumpi

+0

@Simucal Creo que esta debería ser la respuesta aceptada, ¡gracias Trumpi! –

+0

@TonyDay, hecho. Gracias por recordarme. – mmcdole

9

Eso es lo que uso para el control de fuente de mi casa.

Donde solo tengo un repositorio principal.

repositorio/Project1/Tronco
repositorio/Project1/Etiquetas
repositorio/Project1/Ramas

repositorio/Project2/Trunk
repositorio/Project2/Etiquetas
repositorio/Project2/Ramas

Me gusta esta estructura, es muy fácil hacer referencia a los proyectos y mantener la integridad.

Fuente

2009-02-21 20:41:35

+0

Estoy totalmente a favor de este diseño. Escuché lo que dice Pawel, y si los repositorios fueran tan fáciles de crear y administrar en svn como lo son con git, estaría de acuerdo. Pero si puede tratar cada proyecto * como si * fuera su propio repositorio, las cosas simplemente funcionan bien. –

+0

Sí exactamente, en el escenario descrito también parece poco práctico tener un diseño de repositorio múltiple de todos modos.Puede hacer un simple obtener para el repositorio principal para seleccionar todo su código o obtener cada proyecto individualmente. –

+0

También con VS2008 y AnkhSVN 2.0 es muy manejable y fácil de usar Soluciones multiproyectas, etc. –

1

No hay una respuesta clara a esta pregunta, ya que depende de lo que se adapte mejor a sus proyectos.

Utilizaría/projectA/trunk layout si hubiera un gran desarrollo por proyecto y todo debe separarse ya que no hay mucha conexión entre ellos (componentes/proyectos que son independientes). Sin embargo, también podría usar un repositorio SVN por proyecto. Recuerde que no podrá verificar todos los proyectos usando svn co http: //..../svn/ porque esto también obtendrá todas las etiquetas y ramas de todos los proyectos, no solo del tronco.
/trunk/projectA sin duda sería mejor si sus proyectos/componentes pertenecen estrechamente y necesita etiquetarlos y ramificarlos desde la misma revisión (como una biblioteca que pertenece muy de cerca al proyecto principal). También puede usar svn co http: //.../svn/trunk/ para obtener todos los proyectos en su última revisión troncal si lo desea.

Desde un punto de vista de mantenimiento, casi siempre preferiría la segunda manera; pero si sus proyectos crecen y pueden prolongarse, sería mejor usar repositorios separados por proyecto.

Además de eso: compruebe si realmente necesita los servicios de Google Code para su tarea porque su propósito es apoyar OSS. Siempre puede usar SVN localmente o incluso a través de SSH, por lo que también puede colocar sus repositorios en una memoria USB o en alguna computadora a la que se pueda acceder de forma remota; realmente no necesitas alojamiento para eso. También podría haber problemas de privacidad.

Fuente

2009-02-21 20:43:41 Energiequant

+2

Bueno, mi código ~ será ~ de código abierto y el hecho de que sea para la escuela no significa que no tenga ningún valor potencial . Particularmente mi trabajo en Algoritmos Genéticos, las personas pueden encontrarlo valioso para leer. Google-code está diseñado exactamente para esto. – mmcdole

+1

No soy un tipo de Thumbdrive y SVN localmente derrota el propósito de por qué estoy intentando configurar esto en primer lugar. Portabilidad. – mmcdole

+0

Quizás le gustaría probar unfuddle (http://www.unfuddle.com). Le darán un repositorio de svn gratuito y su código puede ser privado. – Trumpi

1

Si insistes en tener solo un repositorio (estoy en el campo NO ME DOY) y haces una bifurcación, entonces creo que lo que propones es bueno. Pero, de nuevo, considero que un repositorio SVN es igual a un proyecto.

Fuente

2009-02-21 20:49:16

+2

Mis proyectos son bastante livianos. El objetivo del repositorio es que pueda trabajar en todos mis pequeños proyectos para la escuela sin tener que llevar el código conmigo a todas partes. Tener un repositorio para cada uno de estos microproyectos sería engorroso. – mmcdole

6

Un ejemplo de la vida real: The Apache Projects repository.

Fuente

2009-02-21 21:25:26

1

Uno de los principales objetivos que rastrea con el diseño de la carpeta (en el control de versiones) es la gestión del control de acceso.

Si existe la necesidad de separar Desarrollar equipo (que trabaja en tronco) y mantener el equipo (que se trata de ramas) de esta estructura es buena:

/trunk 
     /Project1 
     /Project2 
/branches 
     /Project1 
     /Project2 
/tags 
    /Project1 
    /Project2

Y si queremos permitir el acceso de todos los proyectos de un grupo de usuarios específico, esta estructura es buena:

/Project1 
     /trunk 
     /branches 
     /tags 
/Project2 
     /trunk 
     /branches 
     /tags

Fuente

2013-08-03 09:34:40

Estructura de carpetas para muchos proyectos en un repositorio SVN?

Respuesta

Cuestiones relacionadas