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

StackOverflow https://stackoverflow.com/questions/15674

  •  08-06-2019
  •  | 
  •  

Pregunta

Cuando uso Subversion (svn) para el control de código fuente con múltiples proyectos, noté que el número de revisión aumenta en todos los directorios de mis proyectos.Para ilustrar mi diseño svn (usando nombres de proyectos ficticios): 

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

Cuando realizo una confirmación en el tronco del programa Ninja, digamos que obtengo que se actualizó a la revisión 7.Al día siguiente digamos que hago un pequeño cambio en la aplicación Stealth y vuelve como revisión 8.

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

EDITAR: Me demoré en marcar una respuesta porque quedó claro que existen razones para ambos enfoques y, aunque esta pregunta apareció primero, me gustaría señalar algunas otras preguntas que, en última instancia, plantean la misma pregunta:

¿Debo almacenar todos los proyectos en un repositorio o en varios?

¿Un repositorio SVN o muchos?

¿Fue útil?

Solución

Me sorprende que nadie haya mencionado que esto se analiza en Control de versiones con Subversion, que está disponible de forma gratuita en línea. aquí.

Leí sobre el tema hace un tiempo y realmente parece una cuestión de elección personal, hay una buena publicación en el blog sobre el tema. aquí.EDITAR: Dado que el blog parece estar caído, (versión archivada aquí), he aquí algo de lo que Mark Phippard dijo sobre el tema.

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

  1. Administración simplificada.Un juego de ganchos para desplegar.Un repositorio para realizar copias de seguridad.etc.
  2. Flexibilidad de rama/etiqueta.Con el código todo en un repositorio, resulta más fácil crear una rama o etiqueta que involucre múltiples proyectos.
  3. Mueva el código fácilmente.Quizás quieras 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.

Éstos son algunos de los inconvenientes del enfoque de repositorio único y las ventajas del enfoque de repositorio múltiple.

  1. Tamaño.Puede que sea más fácil tratar con muchos repositorios más pequeños que con uno grande.Por ejemplo, si retira un proyecto, puede simplemente archivar el repositorio en un medio, eliminarlo del disco y liberar almacenamiento.Tal vez necesites volcar/cargar un repositorio por algún motivo, como por ejemplo para aprovechar una nueva característica de Subversion.Esto es más fácil de hacer y con menos impacto si se trata de un repositorio más pequeño.Incluso si finalmente desea hacerlo en todos sus repositorios, tendrá menos impacto hacerlo uno a la vez, suponiendo que no exista una necesidad urgente de hacerlo todos a la vez.
  2. Número de revisión global.Aunque esto no debería ser un problema, algunas personas perciben que sí lo es y no les gusta que el número de revisión 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 del repositorio.Si tiene un proyecto al que solo unas pocas personas seleccionadas deben acceder, es más fácil hacerlo con un único repositorio para ese proyecto.
  4. Flexibilidad administrativa.Si tiene varios repositorios, entonces es más fácil implementar diferentes scripts de enlace según las necesidades del repositorio/proyectos.Si desea secuencias de comandos de enlace uniformes, entonces un único repositorio podría ser mejor, pero si cada proyecto quiere su propio estilo de correo electrónico de confirmación, entonces es más fácil tener esos proyectos en repositorios separados.

Si lo piensas bien, los números de revisión en un repositorio de múltiples proyectos aumentarán, pero no te quedarás sin ellos.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.

Otros consejos

Creo que es muy recomendable crear repositorios separados para cada proyecto.Aunque solo sea para evitar el escenario del que estás hablando.

Con el control de versiones, especialmente Subversion, puede extraer fácilmente partes de un repositorio en otra copia de trabajo y luego enviarlas nuevamente a sus respectivos repositorios.Eso le permite mantenerlos claramente separados y distintos, al mismo tiempo que le brinda una gran flexibilidad.Una vez que entres un poco más en SVN (supongo que eres nuevo), puedes comenzar a usar ganchos y podría ver dónde podría resultar difícil con tu configuración.Si los permisos son importantes para usted, un único repositorio puede resultar más difícil de lo necesario.

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

Esto se debe a cómo funciona la subversión.Cada revisión es en realidad una instantánea del repositorio identificado por ese número de revisión.Si todos sus proyectos comparten un repositorio, entonces es inevitable.Normalmente, según mi experiencia, sin embargo, configurarías repositorios separados para proyectos completamente no relacionados.La respuesta corta es no, no estás haciendo nada malo; es una pregunta común en torno a la subversión, pero tiene sentido cuando piensas en cómo almacena la información del repositorio.

El número de revisión en realidad debería ser sólo un identificador de una versión en particular.No debería importar si es secuencial para un proyecto o no.Dicho esto, puedo entender que no sea 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 de SVN para cambiar este comportamiento y, en mi humilde opinión, mantener varios repositorios parece una sobrecarga innecesaria.

Solo tenemos un repositorio con todo lo que contiene, prácticamente exactamente como en su ejemplo.

No veo nada malo en esto; el único requisito para el número de revisión es que sea

  • Único
  • Atómico
  • Más grande que en el último check-in.

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

@grom:

Luego, cada vez que comienzo un nuevo proyecto simplemente ejecuto:

svnadmin create /var/www/svn/myproject

Puedo ver que esto funciona bien si solo tienes 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?

Se recomienda utilizar un repositorio separado por proyecto.En mi directorio Apache conf.d 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>

Luego, cada vez que comienzo un nuevo proyecto simplemente ejecuto:

svnadmin create /var/www/svn/myproject

Hm, donde trabajo tenemos todos nuestros proyectos en el mismo repositorio.Realmente no veo el beneficio de separarlos, ¿no crea eso simplemente mucho trabajo extra: crear nuevos repositorios, otorgar acceso a personas, etc.?Supongo que los repositorios separados tienen sentido si los proyectos no tienen ninguna relación y tienes, por ejemplo, clientes externos que necesitan tener acceso al repositorio.

En mi lugar de trabajo tenemos dos repositorios.Uno con acceso público de lectura 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 de que los números de revisión aumenten con cada actualización.Los números de revisión podrían omitir números primos e pares y aún así hacer lo que se supone que deben hacer.Facilite el acceso a una revisión específica.

Si le molesta que los números de revisión cambien según otros proyectos, coloque los proyectos en repositorios separados.Sólo así se pueden hacer independientes los números de revisión.

Para mí, la gran razón para usar diferentes repositorios es proporcionar un control de acceso separado para los usuarios y/o usar diferentes scripts de enlace.

Quizás sea mejor no crear necesariamente un repositorio por "proyecto", sino un repositorio por "solución" (para usar términos de Visual Studio).Si tiene varios "proyectos" en diferentes carpetas pero están relacionados entre sí, colóquelos en el mismo repositorio.

Almaceno un proyecto por repositorio, y como un anterior comentarista en este pregunta de subversión, Marco los proyectos compartidos como externos, para que solo estén en control de código fuente una vez.

Recién estoy comenzando a agregar un servidor de compilación de 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.

Sin embargo, aparte de la apariencia, en realidad es una cuestión de preferencia (en mi opinión).

Cuando realmente piense, los números de revisión en un repositorio de proyectos múltiples se pondrán drogados, pero no se va a agotarse.Tenga en cuenta que puede ver un historial en un subdirector y ver rápidamente todos los números de revisión que pertenecen a un proyecto.

En realidad, si está compilando código de Microsoft y usa los números de revisión de svn como parte de su cadena de versión, entonces podría quedarse sin él.El compilador de Microsoft arrojará un error si alguna parte de la cadena de versión es mayor que 65535....En nuestro caso, tenemos un repositorio enorme en la revisión 68876 y acabamos de chocar contra este muro.

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 código fuente.

@Daniel Fone:Los documentos SVN recomiendan un proyecto por repositorio, por lo que definitivamente esa es la forma en que los creadores pretendían que fuera.Como puede hacer que un servidor (apache o svnserve) mantenga múltiples repositorios, nunca me he encontrado con un problema de demasiada sobrecarga.Con Servidor VisualSVN, instalar un servidor Apache y configurar varios repositorios es muy sencillo.

No estoy seguro de que los documentos de SVN realmente recomienden un proyecto por repositorio.Principalmente hablan de las ventajas y desventajas de cada camino.Resulta que uso tres repositorios diferentes, uno para 7 u 8 proyectos que están todos relacionados, lo que hace que sea muy agradable poder enviar copias compatibles de todos los proyectos simplemente compilando a partir de una revisión (o verificando que sean compatibles mirando en los números de revisión de 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 administrar con un único número de revisión, pero que los proyectos no relacionados no afectan su repositorio.

Los números de revisión no tienen ningún uso semántico.Lo único es que están en orden secuencial.Si descarta su proyecto y lo importa a otro repositorio, sus versiones pueden obtener nuevos números de revisión.Entonces NUNCA use los números de revisión para marcar sus lanzamientos o cosas similares.Realizar etiquetas para lanzamientos (copias de la revisión correspondiente).

Tuve el mismo problema en mi empresa anterior. Solían tener como 50 proyectos ejecutándose en un repositorio y era una pesadilla trabajar en los mismos proyectos porque cuando hacían actualizaciones de svn otros maldecían...jaja...

He aprendido una cosa que siempre funciona mejor: un proyecto, un repositorio... nunca te arrepentirás.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top