Cómo granulares son sus "proyectos" SVN:. Un proyecto grande que contiene varios "proyectos' aplicaciones releated o uno por aplicación

Question

defino un proyecto como un directorio SVN contiene tronco, las ramas, las etiquetas directorios sub

qué criterios ¿utiliza al determinar cuándo dividir un proyecto en dos o consolidar varios proyectos en uno? - Una aplicación por "Proyecto" con proyectos compartidos para fuentes y recursos comunes? - Un gran "proyecto" que contiene todas las fuentes y recursos para la aplicación?

Un solo proyecto o proyecto múltiple tienen sus ventajas y desventajas. Estamos dirigiendo mo re hacia un solo proyecto y estoy tratando de averiguar si este es el enfoque correcto.

Los proyectos divididos permiten una mayor capacidad para controlar cómo las diferentes partes de la suite incorporan un cambio. La biblioteca común puede ser una versión y diferentes aplicaciones pueden elegir usar una versión específica (enfoque de gestión de depts).

El proyecto dividido también crea jerarquías de clases múltiples, lo que hace que el código sea más difícil de comprender como un todo y potencialmente conduce a la duplicación de código. Asumiría que el diseño apropiado de la estructura general y las relaciones entre los componentes serían claves para manejar este costo.

Un enfoque de proyecto unificado facilitará al desarrollador en términos de configuración de un espacio de trabajo, y proporcionará una jerarquía de clase única. Este es un arma de doble filo, ya que también arrojará mucha más información al desarrollador (demasiadas clases para comprender).

Entonces, cuando está tratando de decidir dónde combinar y dónde dividirse, ¿qué reglas generales usa?

Answer 1

Gracias por la entrada. No voy a "elegir" una respuesta porque creo que todos tienen puntos valiosos en ellos. Evitar la optimización prematura parece clave, al igual que mantener el diseño lo más simple posible por el momento. Nos estamos moviendo a un único proyecto que contiene las aplicaciones porque el 90% de las veces lanzamos TODOS juntos. Por lo tanto, complicar las cosas con una sola aplicación por proyecto no parece tener sentido. Incluso cuando vamos a maven, es probable que todos los artefactos de maven para una versión determinada se hagan desde la misma rama. Siempre podemos cambiarlo más tarde si es necesario usar el historial SVN y el ojo de pez para mantenernos sanos.

Refaccionaremos el diseño de origen de la misma manera que lo haríamos para refactorizar la fuente. Cuando un proyecto comienza a "oler mal" a causa de una circunferencia y una situación de dependencia, lo dividiremos, pero no antes. Probablemente usaré la circunferencia en el tiempo, no la circunferencia en el espacio: tiempo para construir la prueba &, hora de finalizar la compra. Si tengo un árbol de 1GB que puedo pagar en < 10 minutos y construir/probar en < 30 minutos, realmente no necesito separarlo a menos que deba liberar partes de él con frecuencia.

Así que, gracias por la entrada. Fue muy útil para encuadrar la pregunta para mi equipo y evaluar las opciones.

Answer 2

Utilizo proyectos por separado y los combino para formar una solución a través de svn: externals.

Answer 3

El SVN Book tiene una buena discusión en ambos enfoques.

Al final, elegiría lo que sea más natural para los usuarios del repositorio.

Personalmente, he preferido un solo enfoque SVN trunk/tags/branches con todos mis proyectos de código reales en sus propias carpetas dentro de esos.

Sin embargo, para una base de código más grande (solo administré 3-4 proyectos pequeños que formaban parte de una única solución), consideraría cambiar a un enfoque dividido.

Answer 4

Pusimos todos los proyectos relacionados con una sola aplicación dentro de un SVN Rep simplemente por el mantenimiento, centralizando la base de códigos de la aplicación en un solo repositorio y también la capacidad de gestionar las interdependencias entre los diferentes recursos de la aplicación.

generalmente clasificamos nuestros recursos en diferentes carpetas dentro del tronco. esa categorización se basa principalmente en la agrupación funcional/modular o la agrupación en capas [DAL, BLL, GUI, etc.]. eso depende completamente de cómo haya estructurado el código. Espero que esto ayude.

Answer 5

Utilizo proyectos separados y proyectos combinados según el tamaño del proyecto. Para nuestros proyectos grandes, cada uno se encuentra en un repositorio separado y tiene procedimientos de compilación e implementación independientes. Para nuestros proyectos más pequeños, tenemos un repositorio de "herramientas" para contenerlos, con cada subproyecto como un subdirectorio de la raíz.

También tengo un repositorio "personal" donde las personas pueden almacenar sus programas de prueba con utilidades únicas u otras cosas que podrían beneficiarse del control de fuente y respaldos centralizados, pero no como un proyecto independiente.

Answer 6

Una aplicación/módulo que se implementa de forma independiente por proyecto. El uso de un solo proyecto dificulta la introducción de ciclos de publicación si alguna vez descubre que necesita la administración de dependencias de Mavenish con un módulo que depende de implementaciones estables de otros módulos. También puede hacer que las personas simplemente usen código de aspecto aleatorio y útil de otras aplicaciones directamente en lugar de factorizarlo para mantener el gráfico de dependencia Sane (tm).

Debe realizar las pruebas de integración utilizando suites de prueba y prácticas de CI adecuadas en una definición clara, no confiando en que la mitad de su código falle repentinamente si se rompe una parte.

Otro problema con tener un solo proyecto de uber es que es bastante oneroso para los usuarios de git-svn que solo trabajan en un solo módulo.

Answer 7

Guarde repositorios SVN separados para proyectos separados. Lo último que desea es tener un Merge Day

Answer 8

Crecer orgánicamente. La pre optimización es la raíz de todo mal, dijo una vez Dijkstra. También ten en cuenta a YANGI (no lo vas a necesitar).

Cada aplicación obtiene su propia carpeta con trunk/tag/branches. Si el proyecto dentro de una aplicación se vuelve realmente grande, entonces se inserta en su propia carpeta separada y se puede vincular a la aplicación en tiempo de compilación (o incluso svn: externos).

Dicho esto, si los requisitos de su proyecto son desarrollar una aplicación compleja escrita por 10 desarrolladores y usted es el controlador de acceso o maestro de construcción, entonces puede considerar alternativas más complejas.

Answer 9

Es posible que desee comprobar Subversion revision number across multiple projects.

Answer 10

no hay una "buena" respuesta aquí, pero creo que debería haber una distinción entre los repositorios SVN que contienen 1 o 2 proyectos, y otros que contienen 100.

Mantengo un repositorio SVN que se migró de VSS, tiene varios cientos de "proyectos" en él, ninguno de ellos se ha organizado a lo largo de la estructura troncal/rama/etiqueta (de hecho, creo que la estructura es realmente innecesaria y Inútil después de haber usado SVN por un tiempo, ciertamente no ayuda cuando tiene que etiquetar 2 o 3 proyectos como un cambio único.

Mantenemos un directorio de proyecto para todo nuestro software mantenido, debajo de eso tenemos subdirectorios para configuración y otro para fuente. Debajo tenemos números de versión de producto, así que efectivamente estamos descartando el concepto de troncal, solo tenemos directorios de etiquetas, el número más alto es el troncal (tenemos que hacer esto ya que tenemos que admitir varias versiones de los proyectos simultáneamente). La fusión ocurre según sea necesario, por lo que si actualizo un error en el proyecto A, versión 3.0; Combinaré esos cambios a la versión 4.0 y v5.0.

Si tuviera que realizar un repositorio con solo 1 o 2 proyectos, podría estar tentado a mantener la estructura de la rama/etiqueta, pero, por otro lado, probablemente mantendría los directorios explícitos en el árbol principal (asumiendo No publiqué con la frecuencia suficiente para etiquetar regularmente) (utilizo el número de revisión como una 'etiqueta' por cierto, y almaceno binarios allí. Así que si necesito obtener una revisión antigua en particular, puedo tomar el binario correcto de la búsqueda en el registro)

Es sorprendentemente fácil de manejar teniendo en cuenta que tengo un repositorio de 10 Gb con un revnum actualmente más allá de los 300,000 con muchos códigos antiguos tanto allí como más nuevos. Recomendaría la estructura a otros y la usaré de nuevo.

Dicho sea de paso, otro dir de etiquetas de razón no funcionaría para nosotros porque lo lanzamos cada vez que hay un error o una solicitud de cambio, sin importar cuán pequeña sea. Nuestro directorio de etiquetas sería inmanejable después de un tiempo, es por eso que usamos el revnum como una etiqueta, podemos asociarlo con el rastreador de errores para que sea también más legible.

Entonces, para resumir en bruto, tenemos una estructura de directorios como éste, donde v1 y v2 son las versiones del producto:

maint/source/v1.0/projectA 
maint/source/v1.0/projectB 
maint/source/v2.0/projectA 
maint/source/v2.0/projectB 
etc 

obviamente, podríamos poner un directorio rama bajo 'fuente', y una rama/etiqueta también bajo cada subproyecto, pero eso sería complicado si necesitáramos lanzar 2 subproyectos como una solicitud de cambio único (como lo hacemos con bastante frecuencia). Colocar una etiqueta subdir en el directorio de origen significaría que etiquetáramos todo, cuando solo se modificó un subproyecto individual (no se ajusta a nuestro requisito de rastrear cada subproyecto individualmente)