subversion - Múltiples repositorios SVN o repositorio de una sola compañía

tortoise svn (12)

¿Deberíamos tener un repositorio único para toda la empresa, que contiene muchos proyectos de desarrollo o un repositorio por proyecto? ¿Alguna idea sobre la experiencia / mejores prácticas?

Dependerá de cuán interdependientes sean sus aplicaciones / proyectos en la organización, y también cuán grandes sean las bases de códigos. Por lo tanto, se reduce a cómo se define un "proyecto" en su organización. La base de código compartido, los componentes compartidos, los equipos compartidos y los ciclos de lanzamiento compartidos podrían influir en la estructura de los repositorios.

Para simplificar, defino que un proyecto tiene una base de código independiente, un cronograma de lanzamiento y / o pertenece a una herramienta / aplicación. Si este es el caso, prefiero tener un repositorio por proyecto. De esta forma, hay más libertad para definir e implementar políticas / restricciones de acceso por proyecto.

Si tuviera un solo repositorio hinchado con el tiempo ... también podría tener que preocuparme por el tiempo de espera del área de trabajo, etc., especialmente si el código para los proyectos está mezclado. Si una aplicación / herramienta / proyecto es completada / archivada / obsoleta / migrada, puede haber más control en los aspectos de administración si hay separación en el nivel del proyecto.

Estructurar un repositorio de proyecto basado en sus necesidades únicas también puede ser más fácil si hay un repositorio por proyecto. Cada proyecto puede tener necesidades específicas, que pueden afectar las políticas de administración de la configuración (ramificación, etiquetado, convenciones de nomenclatura, CI, etc. incluidas) seguidas para cada proyecto. Esto no quiere decir que no se puede hacer toda esta carpeta en un único repositorio. Usted puede. Simplemente hace las cosas más simples para tener una separación más limpia, eso es todo.

Es posible que desee considerar todos estos factores para evaluar los gastos generales administrativos con los que puede terminar, en función de su configuración específica.

Dicho esto, si los proyectos son todos de pequeño tamaño, y son interdependientes, lo que requiere referencias cruzadas, seguimiento cruzado, movimiento entre sí, etc., entonces es mejor con un repositorio único y una carpeta por repositorio.

Descubrí que tener un único repositorio de Subversion ayuda:

Transparencia : es más fácil seguir lo que está sucediendo y encontrar el código incluso en proyectos en los que puede no estar involucrado directamente.
Mantenimiento : no es necesario crear repositorios cada vez que desee crear un nuevo proyecto, y puede eliminar proyectos completos sin temor a perder el registro de Subversion.
Mantenimiento : solo es necesario tener un repositorio respaldado.

EDITAR: Razones adicionales:

ID de revisión global: al tener ids de revisión globales, es:
1. Más fácil de comunicar (por ejemplo, en una solicitud de revisión de código, simplemente especifique la id. De revisión, sin necesidad de especificar qué proyecto).
2. Es más fácil garantizar la atomicidad cuando los proyectos tienen dependencias entre ellos.
3. Es más fácil ver el orden de las asignaciones a diferentes proyectos.

Estoy trabajando en una empresa que trabaja para muchos clientes con reglas estrictas. Por el momento tenemos alrededor de 130 desarrolladores. Tenemos un proyecto central que se adapta a las necesidades de cada cliente. Y tenemos un enorme repositorio svn. Sería doloroso si tuviésemos que verificar toda la sucursal, pero nuestra estrategia es mover los proyectos fuera de la rama común y dejar el trabajo solo para los comandos de cambio. :) De esta manera todo se puede mantener en un único repositorio.

Mi única preocupación era la división de un repositorio en varios repositorios si era necesario en el caso de que se subasignara parte del trabajo, o la venta de un proyecto completo hasta que encontré esto: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories

Por lo tanto, creo que svn switch alivia el dolor de la comprobación larga (uno solo cambia los proyectos deseados), pero podemos tener un repositorio. Pero, si aún es necesario, uno puede extraer un conjunto de componentes para separar el repositorio.

He hecho ambas cosas y en ambos casos a veces me gustaría haber elegido el otro método ...

Me he establecido en un repositorio es una buena solución. Tenga en cuenta que si estuviera en una compañía más grande lo reconsideraría.

La decisión también puede estar basada en la complejidad del proyecto. Si está empezando un gran esfuerzo que estará separado de la mayoría de todo lo demás en el que trabajará, y tendrá un gran equipo de desarrollo trabajando en ello, puede tener sentido darle un repositorio por separado.

Para los equipos que trabajan en una serie de proyectos más pequeños a la vez, un único repositorio proporciona un mecanismo simple para administrar todo en un solo lugar (copia de seguridad, búsqueda, etc.). El repositorio central también hace que el repositorio en sí mismo parezca un poco más "concreto", ya que no se descartará una vez que el proyecto esté completo o abandonado.

Muy buenas respuestas perspicaces hasta ahora, pero solo quiero agregar mis dos centavos:

Creo que depende del tamaño de tu proyecto. Hemos probado ambos enfoques, pero finalmente lo resolvimos con un gran repositorio.

Contras :

La ramificación puede ser difícil, ya que muchas carpetas y archivos pueden estar involucrados
El repositorio puede volverse ENORME
Debes revisar el repositorio completo (o al menos ramas específicas) para construir tu solución
Un poco menos de control de la arquitectura del proyecto (ver pros)

Pros :

Todos los proyectos comparten el mismo historial de repositorio
La ramificación es para todo el repositorio
Mucho menos administración (los desarrolladores individuales pueden crear nuevos proyectos sin la ayuda de un administrador de sistemas)
Mejor visión general y opciones de supervisión de los commits del repositorio

En mi humilde opinión (y con respecto a nuestro proyecto en particular), los profesionales superan los inconvenientes.

Para mi organización fui a medio camino, creando varios repositorios para diferentes "áreas" de codificación. Sabía de antemano que cada depósito contendría proyectos que estarían bastante separados el uno del otro.

Personalmente, definitivamente preferiría un repositorio separado por proyecto. Hay varias razones:

Números de revisión . Cada repositorio de proyecto tendrá una secuencia de revisiones separada.
Granularidad Con el repositorio por proyecto, simplemente no puede realizar un compromiso en diferentes proyectos con el mismo número de revisión. Supongo que esto es más una ventaja, mientras que alguien diría que es un defecto.
Tamaño del repositorio ¿Qué tan grande es tu proyecto? ¿Tiene binarios bajo control de fuente? Apuesto a que sí. Por lo tanto, el tamaño es importante: cada revisión del archivo binario aumenta el tamaño del repositorio. Eventualmente se vuelve torpe y es difícil de soportar. Se debe respaldar la política detallada de almacenamiento de archivos binarios y proporcionar administración adicional. En cuanto a mí, todavía no puedo encontrar cómo podría eliminar completamente el archivo binario (cometido por un usuario estúpido) y su historial de contenido del repositorio. Con repositorio por proyecto sería más fácil.
Organización interna de repositorios . Prefiero repositorios estructurados, muy organizados, independientes y detallados. Hay un diagram ilustra el enfoque general (ideal) del proceso de mantenimiento del repositorio. Creo que estarían de acuerdo en que NO ES POSIBLE utilizar el enfoque de "todos los proyectos en un solo informe". Por ejemplo, mi estructura inicial de repositorio (cada repositorio de proyecto debería tener) es:
/project /trunk /tags /builds /PA /A /B /releases /AR /BR /RC /ST /branches /experimental /maintenance /versions /platforms /releases
Administración de Repo . ''Repositorio por proyecto'' tiene más posibilidades en la configuración de acceso de los usuarios. Sin embargo, es más complejo. Pero también hay una función útil: puede configurar repositorios para usar el mismo archivo de configuración
Repo Support . Prefiero hacer copias de seguridad de los repositorios por separado. Alguien dice que en este caso no es posible fusionar información de un repositorio a otro. ¿Por qué demonios necesitarías eso? El caso en el que se requiere dicha combinación muestra que el enfoque inicial para el control de la fuente es incorrecto. La evolución del proyecto supone la subsecuente separación del proyecto en submódulos, y no a la inversa. Y sé que hay un enfoque para hacer eso.
svn: externos . El enfoque ''Repositorio por proyecto'' fomenta el uso de svn: external. Esa es una situación saludable cuando las dependencias entre el proyecto y los submódulos se establecen a través de enlaces suaves, que es svn: externals.
Conclusion Si desea mantener el control de fuente simple, use un repositorio. Si desea hacer la gestión de la configuración del software A LA DERECHA:
1. Usar el enfoque ''repositorio por proyecto''
2. Introduzca una función separada del administrador de configuración de software y asigne al miembro del equipo a ella
3. Contratar a un buen administrador, que pueda hacer frente a todos los trucos de subversión :)

PD. Por cierto, a pesar de que trabajo con SVN todo el tiempo y me gusta, el enfoque de "repositorio por proyecto" es la razón por la que veo los sistemas DCVS más atractivos desde el punto de vista de la organización del repositorio. En DCVS, el repo es el proyecto por defecto. Incluso no hay duda de que es posible ''individual versus múltiple'', sería una tontería.

Recomiendo encarecidamente no usar un repositorio por proyecto. Dentro de un único repositorio de subversión, puede mover y copiar datos y retendrá su historial. Si decide que algún fragmento de código que comenzó como una herramienta de back-end se fusiona en el front-end, y que están en diferentes repositorios, esta no es una operación de la que la subversión sepa nada. Será como si hubiera agregado algo al frente de ninguna parte. Esto también significa que no puede realizar fusiones si necesita mantener temporalmente dos versiones del código relacionado.

Notará que todos los ejemplos en el libro svn suponen que todo está en un repositorio.

Hay una pregunta aparte sobre si usar / trunk / project1, / trunk / project2, / branches / project1-r1 o usar / project1 / trunk, / project1 / branches / r1, / project2 / trunk. Generalmente, el segundo es más fácil de seguir.

La mejor razón para no poner todo en un repositorio es que el control de acceso es difícil de hacer de forma más fina que en el nivel de repositorio. Posible, sí, pero no tan fácil. Actualmente tenemos dos repositorios principales:

svn / code para todo el desarrollo de software, requiere jira ticket para confirmar
svn / ops para cualquier configuración, configuración de scripts, tars de terceros, lo que sea, no se requiere jira

Si está utilizando Subversion, podría tener múltiples repositorios bajo el mismo dominio con múltiples proyectos cada uno.

Entonces se vería así

Project1: svn://svn.company.com/project1 Project2: svn://svn.company.com/project2

Project1 podría abordar el código del front-end y contiene subproyectos como admin / y web / Project2, que se ejecutará back-end y contiene varias herramientas y aplicaciones de monitoreo

Si usa algo como Git, cada repositorio debe ser un solo proyecto.

Tendría un repositorio para el proyecto, solo por el hecho de que los números de revisión sean por proyecto. Puede configurar el SVN para que se pueda acceder a todos los proyectos desde un único punto de acceso utilizando Apache y DAV SVN (con la directiva SVNParentPath).

Todo depende de cuántos proyectos tenga, el tamaño de su organización, cuán relacionados estén los proyectos, etc. Si eres parte de un gran equipo con un par de docenas de proyectos, un repositorio por proyecto será bastante difícil de administrar.

Según el tipo de trabajo que realice su organización, otra opción es tener un repositorio por cliente . Donde trabajo, actualmente tenemos cuatro repositorios, uno para proyectos que son completamente internos para nosotros, uno para el software que vendemos y dos que son completamente específicos para clientes particulares para quienes producimos software personalizado que solo se aplica a ellos. Este es un intento de una solución "lo mejor de ambos mundos": no tenemos un repositorio masivo que contenga todo y tenga un número de revisión en los miles de millones (¡exagero obviamente!), Pero tampoco tenemos docenas de pequeños repositorios dando vueltas con un proyecto en cada uno.