Múltiples proyectos svn en una carpeta

Creo que la forma más común de configurar un proyecto en SVN es host/svn/projectA/trunk . Sin embargo, si hay varios proyectos relacionados, ¿podemos tenerlos en una carpeta padre común, o tienen que estar bajo la raíz svn?

es decir

 host/svn/projectA/trunk host/svn/projectB/trunk host/svn/projectC/trunk 

o

 host/svn/parentFolder/projectA/trunk host/svn/parentFolder/projectB/trunk host/svn/parentFolder/projectC/trunk 

Puedes configurar Subversion de la forma que quieras. Los diversos directorys en Subversion no tienen ningún significado para Subversion. El significado lo pone usted. Por ejemplo, conozco a muchas personas que no usan trunk , pero colocan un main bajo el directory branches . De esta manera, todo es una twig que puede facilitar las cosas para hablar y documentar.

La forma estándar (y es solo un estándar porque la mayoría de la gente lo hace de esta manera) es uno de dos methods:

 /trunk/proj1 /trunk/proj2 /branches/1.2/proj1 /branches/1.2/proj2 /tags/1.2/proj1 /tags/1.2/proj2 

Vs.

 /proj1/trunk /proj2/trunk /proj1/branches/1.2 /proj2/branches/1.2 /proj1/tags/1.2 /proj2/tags/1.2 

A veces lo ves así:

 /trunk/proj1 /trunk/proj2 /branches/proj1/1.2 /branches/proj2/1.2 /tags/proj1/1.2 /tags/proj2/1.2 

¿Cómo deberías hacerlo? Yo diría que todo depende de cuán interrelacionados estén los proyectos. Si todos los proyectos tienen el mismo calendar de versión y lanzamiento, colocaría trunk , branches y tags al principio de la URL. Si los proyectos no están relacionados en absoluto, pondría el proyecto primero, y luego tendría cada proyecto con una twig, tags y un tronco separados.

La ventaja de la segunda forma es que no tiene una confusión con qué twig o label va con qué proyecto. Aumenta el espacio de nombres de sus tags y twigs porque cada uno tiene su propia área debajo de cada proyecto.

La desventaja es que debe crear tres directorys nuevos cada vez que crea un proyecto, y si está haciendo una versión común, terminará creando tags separadas para cada uno.

Ah, una desventaja más: si usas svn:externals en un proyecto (algo que normalmente no recomiendo excepto bajo algunas circunstancias muy específicas, y usas URL relativas , arruinarás tu sistema haciéndolo de la segunda manera).

Tenemos un proyecto especial de Ivy que es externo para todos nuestros packages. El package Ivy es una forma de integrar Ivy en nuestros proyectos existentes sin demasiada dificultad. Tenemos los directorys de tags, troncales y twigs en el frente de nuestra URL. En la raíz del proyecto, colocaste la propiedad:

 $ svn ps svn:externals ../ivy.dir ivy.dir . 

Aquí está nuestro layout:

 /branches/1.2/ivy.dir /branches/1.2/project /trunk/ivy.dir /trunk/project /tags/1.2/ivy.dir /tags/1.2/project 

El ../ivy.dir significa upload un directory, luego bajar al proyecto ivy.dir . Cuando ramifico el proyecto (y el proyecto Ivy), el svn:externals no tendrá que ser editado porque apunta a la misma twig. Cuando ivy.dir , también hago el proyecto ivy.dir al mismo time. De nuevo, la URL para svn:externals no cambia porque apuntan a la misma label.

Por lo tanto, puede configurar Subversion de la forma que desee. Usar el estándar significa que cuando ingresan nuevos desarrolladores, saben dónde están las cosas y no tienen que capacitarse. Menos confusión. La gran diferencia es cuán relacionados están los proyectos entre sí. Si están todas ramificadas, labeldas y liberadas juntas, use un set común de branches , tags y directorys trunk . De lo contrario, es mejor que le des a cada proyecto su propio set de branches , tags y directorys de truck .

La forma en que tenemos nuestra configuration está en tu primer ejemplo

host / svn / ..
Proyecto A ..
proyecto B ..
Proyecto c ..
etc

Ha funcionado bien para mí y he estado usando este método durante más de 6 meses.