¿Qué tan grandes son tus proyectos SVN & # 8220; & # 8221 ;: un gran proyecto que contiene varias aplicaciones repetidas o un "proyecto" por aplicación

Question

Defino un proyecto como un directorio SVN que contiene troncales, sucursales, subdirecciones de etiquetas.

¿Qué criterios utilizas para determinar cuándo dividir un proyecto en dos o consolidar varios proyectos en uno solo? - Una aplicación por " Proyecto " ¿Con proyectos compartidos para fuentes y recursos comunes? - Un gran " proyecto " ¿Contiene todas las fuentes y recursos para la aplicación?

Proyecto único o proyecto múltiple tienen sus ventajas y menos. Nos dirigimos más 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 la versión y diferentes aplicaciones pueden optar por utilizar una versión específica (enfoque de gestión de dep de maven).

El proyecto dividido también crea múltiples jerarquías de clase, lo que hace que el código sea más difícil de entender en su conjunto y potencialmente conduce a la duplicación de código. Asumiría que el diseño adecuado de la estructura general y las relaciones entre los componentes serían clave para administrar este costo.

Un enfoque de proyecto unificado hará que sea más fácil para el desarrollador en términos de configurar un espacio de trabajo y proporcionar una jerarquía de clase única. Esta es una espada de doble filo, ya que también arrojará mucha más información al desarrollador (demasiadas clases para comprender).

Entonces, cuando estás tratando de decidir dónde combinar y dónde dividir, ¿qué reglas generales utilizas?

Answer 1

Gracias por la entrada. No lo haré " 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 solo proyecto que contiene las aplicaciones porque el 90% del tiempo lanzamos TODOS juntos. Por lo tanto, complicar las cosas con una 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 realicen desde la misma rama. Siempre podemos cambiarlo más tarde, si es necesario, usar el historial de SVN y el ojo de pez para mantenernos sanos.

Refactorizaremos el diseño de la fuente como lo haríamos con la fuente. Cuando un proyecto comienza a " oler mal " a partir de una situación de circunferencia y dependencia, la dividiremos, pero no antes de eso. Probablemente use la circunferencia en el tiempo, no la circunferencia en el espacio: tiempo para construir y amp; prueba, tiempo de pago. 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 se me exija liberar partes de él con frecuencia.

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

Answer 2

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

generalmente categorizamos 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 es completamente hasta cómo ha estructurado el código. Espero que esto ayude.

Answer 3

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

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

Personalmente, he favorecido un enfoque único de troncales / etiquetas / ramas SVN con todos mis proyectos de código real en sus propias carpetas dentro de esos.

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

Answer 4

Uso proyectos separados y proyectos combinados dependiendo del tamaño del proyecto. Para nuestros proyectos grandes, cada uno está en un repositorio separado y tiene procedimientos independientes de construcción y despliegue. Para nuestros proyectos más pequeños tenemos un " herramientas " Repositorio para contenerlos, con cada subproyecto como un subdirectorio de la raíz.

También mantengo un " personal " Repositorio donde las personas pueden almacenar sus programas de prueba de utilidades únicas u otras cosas que podrían beneficiarse del control de fuente y las copias de seguridad centralizadas, pero que no pertenecen a un proyecto independiente.

Answer 5

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

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 lanzamiento si alguna vez descubre que necesita la gestión de dependencias de Maven -ish con un módulo que depende de implementaciones estables de otros módulos. También puede hacer que las personas utilicen directamente el código de apariencia útil aleatoria de otras aplicaciones en lugar de descartarlo para mantener el gráfico de dependencia Sane (tm).

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

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

Answer 7

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

Cada aplicación tiene su propia carpeta con tronco / etiqueta / ramas. Si un proyecto dentro de una aplicación se vuelve realmente grande, entonces se transfiere a su propia carpeta separada y se puede vincular a la aplicación en el momento de la creación (o incluso svn: externals).

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 el maestro de la construcción, puede considerar alternativas más complejas.

Answer 8

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

Answer 9

Es posible que desee revisar Número de revisión de subversión en múltiples proyectos .

Answer 10

no hay una respuesta 'buena' 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 de SVN que se migró de VSS, tiene varios cientos de "proyectos" en ella, ninguno de ellos se ha organizado a lo largo de la estructura del tronco / rama / etiqueta (de hecho, creo que esa estructura es realmente innecesaria e inútil después de haber usado SVN por un tiempo, ciertamente no ayuda cuando tienes que etiquetar) 2 o 3 proyectos como un solo cambio).

Mantenemos un directorio de proyectos para todo nuestro software mantenido, en virtud del cual tenemos subdirectorios para la configuración y otro para la fuente. Debajo de ellos tenemos números de versión del producto, por lo que efectivamente estamos desechando el concepto de troncal, solo tenemos directorios de etiquetas, el número más alto es el troncal (tenemos que hacerlo ya que tenemos que admitir varias versiones de los proyectos simultáneamente). La fusión se produce 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 hacer un repositorio con solo 1 o 2 proyectos, podría tener la tentación de mantener la estructura de la rama / etiqueta, pero por otro lado, probablemente mantendría los directorios explícitos en el árbol principal (suponiendo que yo no solté con la frecuencia suficiente para etiquetar con regularidad) (uso el número de revisión como un 'tag' BTW, y almaceno binarios allí. Así que si necesito una antigua revisión en particular, puedo tomar el binario correcto al mirar el registro)

Es sorprendentemente fácil de administrar, ya que tengo un repositorio de 10 Gb con un volumen que actualmente supera los 300,000 con muchos códigos antiguos y nuevos. Recomendaría la estructura a otros y la usaré de nuevo.

Por cierto, otra de las razones por las que el directorio de etiquetas no funcionaría es porque lanzamos cada vez que hay un error o una solicitud de cambio, no importa lo pequeña que sea. Nuestro directorio de etiquetas sería inmanejable después de un tiempo, por eso usamos revnum como una etiqueta, podemos asociarlo con el rastreador de errores para mantenerlo más legible para los humanos.

Para resumir, tenemos una estructura de directorios como esta donde v1 y v2 son versiones de 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 de rama bajo 'fuente', y una rama / etiqueta también en cada subproyecto, pero eso sería complicado si tuviéramos que lanzar 2 subproyectos como una única solicitud de cambio (como lo hacemos con bastante frecuencia). Poner una etiqueta subdirigida debajo del directorio de origen significaría que etiquetamos todo, cuando solo se cambió un solo subproyecto (no cumple con nuestro requisito de rastrear cada subproyecto individualmente)