Número de revisión de Subversion en múltiples proyectos

Question

Al usar Subversion (svn) para control de fuente en múltiples proyectos, he notado que el número de revisión aumenta en todos los directorios de mis proyectos. Para ilustrar mi diseño SVN (usando los nombres de proyectos ficticios):

 
    /NinjaProg/branches 
       /tags 
       /trunk 
    /StealthApp/branches 
       /tags 
       /trunk 
    /SnailApp/branches 
      /tags 
      /trunk 

Al realizar un envío al tronco del Programa Ninja, digamos que recibo de que ha sido actualizado a la revisión 7. Al día siguiente, digamos que realizo un pequeño cambio a la aplicación Stealth y vuelve como revisión 8.

La pregunta es: ¿Es una práctica común aceptar, al mantener múltiples proyectos con un servidor de Subversion, tener una revisión de proyectos no relacionados? aumento de número en todos los proyectos? ¿O lo estoy haciendo mal y debería crear repositorios individuales para cada proyecto? ¿O es algo completamente diferente?

EDIT: Me retrasé en marcar una respuesta porque había quedado claro que hay razones para ambos enfoques, y aunque esta pregunta fue lo primero, me gustaría señalar algunas otras preguntas que en última instancia están pidiendo al misma pregunta:

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

Answer 1

Me sorprende que no haya mencionado que esto se discute en el Control de versiones con Subversion, que está disponible en línea gratis, here.

Hace un tiempo leí sobre el tema y realmente parece una cuestión de elección personal, hay una buena publicación en el blog sobre el tema here. EDITAR: Dado que el blog parece estar inactivo, (archived version here), aquí hay algo de lo que Mark Phippard tuvo que decir sobre el tema.

Estas son algunas de las ventajas del enfoque de repositorio único.

1. Administración simplificada. Un conjunto de ganchos para implementar. Un repositorio para hacer una copia de seguridad. etc.
2. Branch/tag flexibility. Con el repositorio de código todo en uno, facilita la creación de una rama o etiqueta que implique varios proyectos.
3. Mueva el código fácilmente. Quizás desee tomar una sección de código de un proyecto y usarla en otro, o convertirla en una biblioteca para varios proyectos. Es fácil mover el código dentro del mismo repositorio y conservar el historial del código en el proceso.

A continuación se enumeran algunos de los inconvenientes del enfoque de repositorio único, ventajas para el enfoque de repositorio múltiple.

1. Tamaño. Podría ser más fácil tratar con muchos repositorios más pequeños que uno grande. Por ejemplo, si retira un proyecto, puede archivar el repositorio en los medios y eliminarlo del disco y liberar el almacenamiento. Tal vez necesite volcar/cargar un repositorio por alguna razón, como para aprovechar una nueva característica de Subversion. Esto es más fácil de hacer y con menos impacto si es un repositorio más pequeño. Incluso si finalmente desea hacerlo a todos sus repositorios, tendrá menos impacto hacerlos uno a la vez, suponiendo que no haya una necesidad apremiante de hacerlos todos a la vez.
2. Número de revisión global. Aunque esto no debería ser un problema, algunas personas lo perciben como uno y no les gusta ver que el número de revisiones avance en el repositorio y que los proyectos inactivos tengan grandes lagunas en su historial de revisiones.
3. Control de acceso. Si bien el mecanismo de autenticación de Subversion le permite restringir el acceso según sea necesario a partes del repositorio, aún es más fácil hacerlo a nivel de repositorio. Si tiene un proyecto al que solo deben acceder unas pocas personas selectas, es más fácil hacerlo con un solo repositorio para ese proyecto.
4. Flexibilidad administrativa. Si tiene múltiples repositorios, entonces es más fácil implementar diferentes scripts de gancho basados ​​en las necesidades del repositorio/proyectos. Si desea que los scripts gancho uniformes, a continuación, un único repositorio podría ser mejor, pero si cada proyecto quiere su propio estilo comprometerse correo electrónico, entonces es más fácil tener aquellos proyectos en los repositorios separados

Cuando usted realmente piensa, los números de revisión en un repositorio de proyectos múltiples van a aumentar, pero no se agotará. Tenga en cuenta que puede ver un historial en un subdirectorio y ver rápidamente todos los números de revisión que pertenecen a un proyecto.

Answer 2

Esto es debido a cómo funciona la subversión. Cada revisión es realmente una instantánea del repositorio identificado por ese número de revisión. Si todos sus proyectos comparten un repositorio, entonces es inevitable. Por lo general, en mi experiencia, sin embargo, configuraría repositorios separados para proyectos completamente independientes. Así que la respuesta corta es que no está haciendo nada incorrecto, es una pregunta común en torno a la subversión, pero tiene sentido cuando se piensa en cómo almacena la información del repositorio.

Answer 3

Almacenar un proyecto por repositorio, y como un commenter anterior en este subversion question, marco los proyectos compartidos como externos, de modo que solo estén en control de fuente una vez.

Estoy empezando a agregar un servidor de compilación CI (CruiseControl.NET), así que tendré que ver cómo funciona todo, pero si mis scripts de compilación son correctos no debería ser un problema.

Aparte del aspecto, es realmente una cuestión de preferencia (en mi opinión).

Answer 4

El número de revisión solo debería ser realmente un identificador para una versión en particular. Si es secuencial para un proyecto o no, no debería importar. Dicho esto, puedo entender que es menos que ideal.

La mayoría de los proyectos que he encontrado se han configurado en un único repositorio y los identificadores de revisión se comportan de esta manera. No conozco ninguna opción de configuración SVN para cambiar este comportamiento, y en mi humilde opinión, mantener múltiples repositorios parece una sobrecarga innecesaria.

Answer 5

Creo que es muy recomendable que cree repositorios separados para cada proyecto. Si no fuera por nada más que para evitar el escenario del que estás hablando.

Con el control de versiones, especialmente Subversion, puede verificar fácilmente las piezas de un repositorio en otra copia de trabajo y luego enviarlas de vuelta a sus respectivos repositorios. Eso le permite mantenerlos claramente separados y diferenciados a la vez que le brinda una gran flexibilidad. Una vez que ingresas a SVN un poco más (supongo que eres nuevo) puedes comenzar a usar ganchos y es posible que veas dónde puede ser difícil hacerlo con tu configuración.Si el permiso es importante para usted, un único repositorio puede resultar más difícil de lo necesario.

Además, si le preocupa que lleve mucho tiempo configurar cada vista de repositorio en la variable SVNParentPath para el archivo de configuración de Apache. (De nuevo, supongo que está usando Apache).

Answer 6

Recomendado para usar un repositorio por proyecto. En mi directorio conf.d de Apache tengo subversion.conf que contiene:

<Location /svn> 
    DAV svn 
    SVNParentPath /var/www/svn 

    AuthType Basic 
    AuthName "Subversion Repository" 
    AuthUserFile /var/www/svn/password 
    Require valid-user 
</Location> 

Entonces cada vez que empiezo un nuevo proyecto que acabo de correr:

svnadmin create /var/www/svn/myproject 

Answer 7

Un repositorio por proyecto.

El comentario de Steven Murawski sobre CC.NET es interesante. Me interesaría saber cómo funciona si necesita especificar varios repositorios de control de origen.

Answer 8

Si te molestan los números de revisión basados ​​en otros proyectos, coloca los proyectos en repositorios separados. Esa es la única forma de hacer que los números de revisión sean independientes.

Para mí, la razón principal para utilizar repositorios diferentes es proporcionar control de acceso por separado para los usuarios y/o usar diferentes scripts de gancho.

Answer 9

Hm, donde trabajo tenemos todos nuestros proyectos en el mismo repositorio. Realmente no veo el beneficio de separarlos, ¿no es que eso crea mucho trabajo extra -crear nuevos repositorios, otorgar acceso a personas, etc.? Creo que los repositorios separados tienen sentido si los proyectos no están relacionados y usted tiene, por ejemplo, clientes externos que necesitan tener acceso al repositorio.

Answer 10

En mi lugar de trabajo, tenemos dos repositorios. Uno con acceso de lectura público y otro para todo lo demás. Usaría solo uno para todo, pero necesitamos diferentes derechos de acceso para proyectos públicos/privados.

Dicho esto, personalmente no veo el problema con el aumento de los números de revisión en cada actualización. Los números de revisión podrían omitir los números primos y pares y aún así hacer lo que se supone que debe hacer. Facilite acceder a una revisión específica.

Answer 11

@ Daniel Fone: Los documentos SVN recomiendan un proyecto por repositorio, por lo que es sin duda la forma en que los creadores pretendían que fuera. Como puede tener un servidor (apache o svnserve) que mantenga varios repositorios, nunca me he encontrado con un problema de demasiada sobrecarga. Con VisualSVN Server, la instalación de un servidor apache y la configuración de múltiples repositorios es muy fácil.

Answer 12

No estoy seguro de que los documentos SVN realmente recomienden un proyecto por repositorio. En su mayoría, hablan sobre las ventajas y desventajas de cada camino. Utilizo tres repositorios diferentes, uno para 7 u 8 proyectos que están relacionados, lo que hace que sea muy agradable poder enviar copias compatibles de todos los proyectos simplemente construyendo a partir de una revisión (o verificando que sean compatibles al mirar). en los números de revisión en cada uno). El segundo repositorio tiene otro grupo de proyectos y documentos relacionados, mientras que el tercero es mucho más pequeño. Eso nos permite aprovechar el hecho de que los proyectos relacionados se pueden gestionar con un solo número de revisión, pero que los proyectos relacionados no afectan a su repositorio.

Answer 13

Sólo tenemos un repositorio con todo su contenido, más o menos exactamente como su ejemplo.

no puedo ver nada de malo en esto - el único requisito para el número de revisión es que es

• único
• Atómica
• grande de lo que era en el último registro

No importa si aumenta en 1 o 50 con cada confirmación en lo que a mí respecta.

@grom:

Entonces cada vez que empiezo un nuevo proyecto en el que acaba de ejecutar:

svnadmin create /var/www/svn/myproject

Puedo ver que esto funciona bien si usted ha conseguido solamente 1 o 2 desarrolladores, pero ¿qué sucede si las personas que están creando nuevos proyectos no tienen acceso de shell en el servidor SVN para poder crear directorios en/var/www?

Answer 14

Los números de revisión no tienen un uso semántico. Lo único es que están en orden secuencial. Si vuelca su proyecto e lo importa en otro repositorio, sus versiones pueden obtener nuevos números de revisión. Así que NUNCA utilice los números de revisión para marcar sus lanzamientos o cosas similares. Haga etiquetas para lanzamientos (copias de la revisión relevante).

Answer 15

Tuve el mismo problema en mi empresa anterior, solían tener como 50 proyectos en ejecución en un repositorio y era una pesadilla trabajar en los mismos proyectos porque al hacer las actualizaciones de svn, otros maldecían .... jaja. ..

Una cosa que he aprendido que siempre funciona mejor, One project One Repo ... nunca te arrepentirás.

Answer 16

Quizás sea mejor no hacer necesariamente un repositorio por "proyecto", sino más bien un repositorio por "solución" (para usar los términos de Visual Studio). Si tiene un grupo de "proyectos" en carpetas diferentes pero están relacionados entre sí, póngalos en el mismo repositorio.

Answer 17

Cuando usted realmente piensa, los números de revisión en un repositorio del proyecto múltiple van a llegar alto, pero no se van a ejecutar a cabo. Tenga en cuenta que puede ver un historial en un subdirectorio y para ver rápidamente todos los números de revisión que pertenecen a un proyecto.

En realidad, si su código de construcción de Microsoft, y utiliza los números de revisión svn como parte de su cadena de versión, entonces podría agotarse. El compilador de Microsoft arrojará un error si alguna parte de la cadena de la versión es mayor que 65535 ... En nuestro caso, tenemos un repositorio masivo en la revisión 68876 y acabamos de llegar a este muro.