tag - tortoise svn server
Número de revisión de Subversion en múltiples proyectos (17)
Cuando realmente piensas, los números de revisión en un repositorio de proyectos múltiples van a aumentar, pero no te vas a 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.
En realidad, si construyes el código de Microsoft y usas los números de revisión de svn como parte de la cadena de tu versión, entonces podrías agotarte. 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.
Cuando utilizo Subversion (svn) para el control de fuente con 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 de svn (usando nombres de proyectos ficticios):
/NinjaProg/branches /tags /trunk /StealthApp/branches /tags /trunk /SnailApp/branches /tags /trunk
Cuando realizo un commit en el tronco del Programa Ninja, digamos que obtengo que se haya 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 la revisión 8.
La pregunta es esta: ¿es una práctica comúnmente aceptada que, al mantener múltiples proyectos con un servidor de Subversion, aumente el número de revisiones de los proyectos no relacionados en todos los proyectos? ¿O lo estoy haciendo mal y debería estar creando repositorios individuales para cada proyecto? ¿O es algo completamente diferente?
EDITAR: 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 finalmente hacen la misma pregunta:
¿Debo almacenar todos los proyectos en un solo repositorio o múltiplex?
@Daniel Fone: los documentos de SVN recomiendan un proyecto por repositorio, así que definitivamente es la forma en que los creadores intentaron hacerlo. Como puede tener un servidor (apache o svnserve) que mantenga varios repositorios, nunca me he encontrado con un problema de demasiada sobrecarga. Con el Servidor VisualSVN , instalar un servidor Apache y configurar varios repositorios es muy fácil.
Almaceno un proyecto por repositorio, y como un commenter anterior sobre esta pregunta de subversión , marco 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 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 del aspecto, es realmente una cuestión de preferencia (en mi opinión).
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 ver fácilmente las piezas de un repositorio en otra copia de trabajo y luego volver a enviarlas 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 llevará mucho tiempo configurar cada vista de repositorio en la variable SVNParentPath para el archivo de configuración de Apache. (De nuevo, supongo que estás usando Apache).
El número de revisión realmente debería ser solo un identificador para una versión 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.
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.
Esto se debe 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.
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.
Los números de revisión no tienen 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 uses los números de revisión para marcar tus lanzamientos o cosas similares. Haga etiquetas para lanzamientos (copias de la revisión relevante).
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, aquí hay una buena publicación en el blog sobre el tema. EDIT: dado que el blog parece estar inactivo, ( versión archivada aquí ), aquí hay algo de lo que Mark Phippard dijo sobre el tema.
Estas son algunas de las ventajas del enfoque de repositorio único.
- Administración simplificada Un conjunto de ganchos para implementar. Un repositorio para hacer una copia de seguridad. etc.
- Flexibilidad de rama / etiqueta. Con el repositorio de código todo en uno, facilita la creación de una rama o etiqueta que implique varios proyectos.
- Mueve 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.
Estos son algunos de los inconvenientes del enfoque de repositorio único, ventajas del enfoque de repositorio múltiple.
- 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.
- 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.
- 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.
- 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 scripts de gancho uniforme, 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.
Cuando realmente piensas, los números de revisión en un repositorio de proyectos múltiples van a aumentar, pero no te vas a 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.
No estoy seguro de que los documentos de 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.
Recomendado para usar repositorio 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>
Entonces cada vez que empiezo un nuevo proyecto, simplemente ejecuto:
svnadmin create /var/www/svn/myproject
Si tener los números de revisión cambian en función de otros proyectos le molesta, luego coloque los proyectos en repositorios separados. Esa es la única forma de hacer que los números de revisión sean independientes.
Para mí, la gran razón para usar repositorios diferentes es proporcionar control de acceso por separado para los usuarios y / o usar diferentes scripts de gancho.
Solo tenemos un repositorio con todo lo que contiene, más o menos exactamente como su ejemplo.
No veo nada malo con esto: el único requisito para el número de revisión es que es
- Único
- Atómico
- Más grande de lo que era en la última comprobación
No importa si aumenta en 1 o 50 con cada compromiso en lo que a mí respecta.
@grom:
Entonces cada vez que empiezo un nuevo proyecto, simplemente ejecuto:
svnadmin create /var/www/svn/myproject
Puedo ver que 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?
Tal vez es 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.
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 aprendí siempre es la mejor, One project One Repo ... nunca te arrepentirás.
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.