52 votos

Múltiples Repositorios SVN o sola empresa repositorio

En caso de tener un único repositorio para toda la compañía, la cual contiene muchos de los proyectos de desarrollo, o de un repositorio por proyecto? Cualquier ideas sobre la experiencia de los / las mejores prácticas?

39voto

Avi Puntos 14468

He encontrado que el tener un único repositorio de Subversion sida en:

  1. Transparencia: es más fácil seguir lo que está pasando, y encontrar código, aun en los proyectos que pueden no estar directamente involucrado.
  2. Mantenimiento: no es necesario crear repositorios cada vez que quiera crear un nuevo proyecto, y puede eliminar toda proyectos sin miedo a perder el registro de la Subversión.
  3. Mantenimiento: sólo es necesario disponer de un repositorio de la copia de seguridad.

EDICIÓN: Razones adicionales:

  • Revisión Global de ids por tener la revisión de los identificadores de ser global es:
    1. Más fácil de comunicarse (por ejemplo, en un código de solicitud de revisión, sólo tiene que especificar la revisión id, sin necesidad de especificar qué proyecto).
    2. Más fácil de garantizar la atomicidad cuando los proyectos tienen dependencias en cada uno de los otros.
    3. Más fácil ver el orden de los compromete a los diferentes proyectos.

37voto

altern Puntos 2435

Personalmente yo definitivamente prefiero repositorio separado por proyecto. Hay varias razones:

  1. Números de revisión. Cada repositorio del proyecto se han separado de las revisiones de la secuencia.

  2. Granularidad. Con el repositorio por proyecto simplemente no se puede hacer un commit en diferentes proyectos que tienen el mismo número de revisión. Asumo esto como ventaja, mientras que alguien diga que es un defecto.

  3. Repositorio de tamaño. ¿Qué tan grande es tu proyecto? No se tienen los archivos binarios bajo control de código fuente? Yo apuesto a que no tiene. Por lo tanto, el tamaño es importante, en cada revisión de archivos binarios aumenta el tamaño del repositorio. Finalmente, se vuelve torpe y difícil de apoyo. De grano fino política de los archivos binarios de almacenamiento debe ser apoyado y administración adicional proporcionada. En cuanto a mí, todavía no puedo encontrar cómo puedo eliminar completamente el archivo binario (cometido por algún estúpido de usuario) y su contenido de la historia desde los repositorios. Con el repositorio por proyecto sería más fácil.

  4. Interior del repositorio de la organización. Yo prefiero la de grano fino, muy organizado, autónomo, estructurado repositorios. Hay un diagrama que ilustra general (ideal) enfoque de repositorio proceso de mantenimiento. Creo que estaríamos de acuerdo en que NO es POSIBLE el uso de 'todos los proyectos en una repo". Por ejemplo, mi primera estructura de 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
    
  5. Repo de administración. 'Repositorio por proyecto' tiene más posibilidades de acceso de los usuarios de la configuración. Es más complejo, aunque. Pero hay también una característica útil: puede configurar los repositorios para usar el mismo archivo de configuración

  6. Repo De Apoyo. Yo prefiero la copia de seguridad de los repositorios por separado. Alguien dice que en este caso no es posible combinar información de un repo en el otro. ¿Por qué en la tierra se necesitaría? El caso cuando dicha combinación se requiere muestra que el enfoque inicial de control de código fuente está mal. De la evolución del proyecto asume proyecto posterior separación en submódulos, y no de otra manera. Y sé que no es el enfoque para hacerlo.

  7. svn:externals. 'Repositorio por el proyecto" enfoque alienta a svn:externals de uso. Esa es una situación saludable cuando las dependencias entre el proyecto y los submódulos se establece a través de enlaces simbólicos, que svn:externals.

    Conclusión. Si desea mantener el control de código fuente simple, el uso de un repositorio. Si desea realizar la configuración del software de gestión de la DERECHA:

    1. El uso de 'repositorio por el proyecto" enfoque
    2. Introducir el papel independiente de software de configuration manager y asignar miembros del equipo para que
    3. Alquiler de buen administrador, que puede hacer frente a todas subversión trucos :)

PS. Por el camino, a pesar que trabajo con SVN todo el tiempo y me gusta, 'repositorio por proyecto' enfoque es la razón por la que yo veo DCVS sistemas más atractiva desde el repositorio de la organización punto de vista. En DCVS repo es el proyecto de forma predeterminada. Incluso hay ninguna pregunta 'sola vs múltiples' posible, sería una tontería.

16voto

Kevin Peterson Puntos 4456

Recomiendo encarecidamente no utilizar un repositorio por proyecto. Dentro de un único repositorio de subversion, puede mover y copiar datos y conservará su historia. Si usted decide que alguna pieza de código que comenzó como un servidor de la herramienta está siendo fusionado en el extremo delantero, y los que están en diferentes repositorios, esto no es una operación que la subversión se sabe nada acerca de. Será como si usted añade algo a la parte delantera de la nada. Esto también significa que usted no puede hacer fusiona si usted necesita para mantener temporalmente dos versiones de código relacionado.

Usted se dará cuenta de que todos los ejemplos en el svn libro asumir que todo está en un solo repositorio.

Hay otra cuestión de si se debe usar /trunk/proyecto1 /trunk/project2, /sucursales/project1-r1 o utilizar /proyecto1/tronco /proyecto1/sucursales/r1 /project2/tronco. Generalmente, el segundo es más fácil seguir la pista.

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

  • svn/código para todo el desarrollo de software, requiere de jira billete para cometer
  • svn/ops para cualquier configuración, configurar los scripts de terceros de brea, lo que sea, no se requiere de jira

8voto

Critical Skill Puntos 1554

Esto depende de la interdependencia de sus aplicaciones/proyectos están en la organización, y también cómo el gran códigos base.Así que todo se reduce a cómo se define un "proyecto" en su organización. Código compartido, los componentes compartidos, comparte los equipos, compartida ciclos de lanzamiento, podría influir en cómo los repositorios necesita ser estructurado.

Para la simplicidad, definir un proyecto independiente, codebase, de liberación de la línea de tiempo y/o la pertenencia a una herramienta/aplicación.Si este es el caso, prefiero tener un repositorio por proyecto. De esta manera hay más libertad para definir y aplicar políticas y restricciones de acceso por proyecto.

Si yo tuviera un único repositorio de distensión con el tiempo ..yo también necesita preocuparse por el espacio de trabajo de la hora de salida, etc., especialmente si el código de los proyectos están todos mezclados. Si una aplicación/herramienta/el proyecto se completó/archivado/obsoletos/emigrado, no puede haber más control en la administración de los aspectos si hay una separación a nivel de proyecto.

La estructuración de un proyecto de repositorio basado en sus necesidades únicas también puede ser más fácil si existe un repositorio por proyecto. Cada proyecto puede tener necesidades específicas, que pueden afectar a la configuración de las políticas de gestión (ramificación, el etiquetado, las convenciones de nomenclatura, CI, etc incluido) seguido para cada proyecto. Esto no es para decir que no se puede hacer todo de esta carpeta sabio dentro de un único repositorio. Usted puede. Sólo guarda las cosas más simples tienen un limpiador de separación - que es de todos.

Usted puede desear para considerar todos estos factores a fin de evaluar los gastos generales de administración usted puede terminar para arriba con, basado en su configuración.

Dicho esto, si los proyectos son de pequeño tamaño, y son interdependientes , que requieren referencias cruzadas, de la cruz de seguimiento, el movimiento dentro de cada uno de los otros, etc., entonces, usted está mejor con una sola repo y una carpeta por cada repositorio.

3voto

reko_t Puntos 22121

Me gustaría tener un repositorio para el proyecto, sólo por el bien de la revisión de los números en cada proyecto. Usted puede instalación de SVN para ser servido, de modo que todos los proyectos se puede acceder desde un único punto de acceso usando el Apache y el DAV SVN (con la directiva SVNParentPath).

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X