¿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?Repositorios SVN múltiples o repositorio de una sola compañía
Personalmente, definitivamente preferiría un repositorio 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.
Repository size. ¿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 del repositorio. Prefiero repositorios estructurados, muy organizados, independientes y detallados. Hay un diagram que 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 del repositorio (cada repositorio del proyecto debe tener) es:
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
administración 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: you can configure repositories to use the same config file
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: externals. 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.
Conclusión. Si desea mantener el control de código fuente simple, use un repositorio. Si desea hacer a la derecha de gestión de configuración de software:
PS. 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.
¿con qué frecuencia observa los números de revisión? Si necesita conservar un compromiso específico, entonces es más fácil crear una etiqueta. – Nick
@Nick. ¿Cómo fusionarías entre las revisiones de un solo módulo cuando no necesitas ver los cambios en otras partes de la aplicación?Para aplicaciones grandes, sería el desastre. Creo que incluso si tiene un repositorio pequeño, es mejor tener consistencia en los números de revisión. Aún así, los números de revisión no son la única razón que podría conducir a uno a usar repositorios separados por enfoque de proyecto. – altern
Si tiene acoplamiento entre proyectos, me inclinaría hacia un único repositorio para el argumento de atomicidad anterior. Esto hace posible la trazabilidad entre revisiones, etiquetas, sucursales y lanzamientos. Dado un número de revisión, puede reproducir la fuente completa de los productos que sabe que funcionarán juntos. –
Si está utilizando Subversion, podría tener varios repositorios bajo el mismo dominio con múltiples proyectos cada uno.
así que sería tener este aspecto
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Proyecto1 podría abordar código de front-end y contiene sub-proyectos como admin/y web/ Project2 sería backend 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 son 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).
+1 para la numeración de revisión. Buen punto. – phidah
Los números de revisión no son un gran problema, lo que Avi menciona realmente es. –
Dado que todas las ramas también usan números de revisión, el argumento del número de revisión es una pista falsa. Ningún proyecto que tenga ramas tendrá números de revisión secuencial en el tronco. –
he encontrado que tiene un único depósito de la subversión en ayudas:
EDIT: razones adicionales:
Buenos puntos, aunque estoy de acuerdo con reko_t en la numeración de revisión. – phidah
No estoy de acuerdo con la numeración de la revisión. Agregué los motivos de mi respuesta. – Avi
La transparencia puede verse como una ventaja o como un inconveniente. Pienso en proyectos que los clientes requieren confidencialidad. – mouviciel
os recomiendo 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.
se dará cuenta de que todos los ejemplos en el svn book asumen todo está en un repositorio.
Hay una pregunta separada sobre si se debe 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 hacer más de grano fino que a nivel de repositorio. Posible, sí, pero no tan fácil. Actualmente tenemos dos repositorios principales:
Pero ** I ** recomendamos encarecidamente no utilizar un repositorio * para todos los proyectos * – altern
La decisión no siempre es tan obvia. En mi compañía trabajamos en proyectos completamente separados para diferentes clientes, en este caso tener un repositorio por proyecto es perfectamente razonable. –
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 repo 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 sencillo de manejar todo en un solo lugar (copia de seguridad, buscar, 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.
Depende 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 un proyecto que 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 único repositorio de distensión con el tiempo ..I también tenga que preocuparse por el tiempo de pagar espacio de trabajo, etc., especialmente si el código de los proyectos están todos mezclados. 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.
Estructuración de un repositorio del proyecto en función de sus necesidades particulares 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 tener en cuenta todos estos factores con el fin de evaluar los gastos generales de administración que puede terminar con, en base a su configuración específica.
Dicho esto, si los proyectos son todos de pequeño tamaño, y son interdependientes, que requieren referencias cruzadas, seguimiento cruzado, movimiento entre sí, etc., entonces es mejor con un repositorio único y una carpeta por repositorio.
muy buenas respuestas interesantes, hasta el momento, pero sólo quiero añadir mi granito de arena:
Creo que depende del tamaño de su proyecto. Hemos probado ambos enfoques, pero finalmente hemos resuelto con un gran repositorio.
Contras:
Pros:
EN MIEMBRO (y con respecto a nuestro proyecto particular) los profesionales superan a los contras.
Todo depende de la cantidad de proyectos que 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.
Para mi organización fui a mitad de 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.
que he hecho tanto y en ambos casos a veces me gustaría que había elegido el otro método ...
me he decidido por un repositorio es una buena solución. Tenga en cuenta que si estuviera en una compañía más grande lo reconsideraría.
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 para múltiples repositorios si es necesario en caso de OUTSORCING parte de la obra, o la venta de un proyecto completo hasta que encontré esto: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories
Así que creo svn switch facilita la el dolor de la comprobación larga (uno solo cambia los proyectos deseados), sin embargo, podemos tener un repositorio. Pero, si aún es necesario, uno puede extraer un conjunto de componentes para separar el repositorio.
en mi experiencia, se podría ir razonablemente de cualquier manera. –
En nuestra organización, tenemos _muchos_ proyectos no relacionados, principalmente .NET. Estamos considerando usar repositorios en el nivel de solución. De esta forma, los proyectos relacionados estarían en el mismo repositorio y compartirían números de revisión, pero no proyectos no relacionados. Creo que lo que debe reducirse es mantener las cosas relacionadas entre sí. Si todos sus proyectos están relacionados, entonces un repos tiene sentido. Si no, entonces ya no tiene sentido. –