Definición de límites en términos de repositorios.

Question

Estableceré la escena primero ...

Usamos Subversion y actualmente tenemos un repositorio principal bastante grande. Sin embargo, estoy intentando descomponerlo, con la posibilidad de mudarme a Git en una fecha posterior. La razón es que a) Git no puede realizar desprotecciones de subcarpetas, por lo que favorece a los repos más pequeños, b) podemos usar mucho más ramificación (rama por función).

Tenemos una aplicación web, y también una aplicación de automatización web.

No dependen directamente unos de otros en términos de código. Pero la aplicación de automatización depende de la aplicación web en términos de diseño. Si se realiza un cambio en la aplicación web, podría interrumpir la aplicación de automatización.

Me gustaría dividirlos en repo por separado, pero se planteó un buen punto. Es útil tenerlos en el mismo repositorio, para que sepas que en cierta revisión ambos trabajaron juntos.

Resolverlo con dos repo separados, con dos conjuntos de números de revisión obviamente es bastante complicado. El otro problema es que tenemos una serie de aplicaciones (no solo de automatización que dependen unas de otras, API, etc.).

Solo quería ver los pensamientos de las personas. Si ha tratado con tal problema? ¿Crees que deberían o no deberían dividirse, etc.? ¿Usas algún tipo de herramienta de implementación para rastrear las distintas revisiones de cada repositorio trabajando juntos, etc.?

Answer 1

primero, creas un clon de tu repositorio svn, luego puedes dividir el repositorio de git resultante con git filter-branch .

para volver a depender los dos proyectos, use submódulos. De esta manera, se puede usar un repositorio con una revisión fija (útil para las bibliotecas, en su caso, la aplicación web)

Answer 2

En términos de herramientas, si crea utilizando Hudson , realiza un seguimiento del conjunto de repositorios y números de revisión utilizados en cada compilación para usted. Puedes etiquetar de esto si es necesario.

Si tiene una herramienta que funciona de esta manera, entonces no es tan importante limitar el número de números de revisión que está rastreando. Lo dividí así: 1 número se puede rastrear manualmente, > 1 necesita soporte de herramientas. Pero no necesitan ser herramientas complejas.

Prefiero un solo repositorio, pero eso es solo una preferencia personal. Se basa en que un número de revisión no es ambiguo, con múltiples repositorios necesita el repositorio y el número. Los límites de repo están luego en los cambios de políticas (por ejemplo, este se usa para el código, este para los documentos de la empresa, este para la implementación, etc.).

Git simplemente no funciona de esa manera, por lo que no tiene la opción de usar un solo repositorio. Eso no es algo malo, y la mayoría de los sistemas (como Hudson, Redmine) estarán felices de apoyar esto.

Answer 3

Dividirlos les permite lanzar de forma independiente, con sus propios números de versión, pero como se nota, realizar un seguimiento de las dependencias puede ser complicado. Pasamos de una compilación basada en Ant a maven para ayudarnos con nuestras dependencias y, a pesar de algunos problemas iniciales, ha valido la pena en general. (Tenemos varias aplicaciones que dependen de las API de los demás de formas extrañas y maravillosas). El esquema básico que seguimos es usar Numeración de versiones de Apache Portable Runtime , que es un sistema de tres dígitos en el que las versiones utilizan una convención estándar MAJOR.MINOR.PATCH.

En cuanto al proceso para dividirlos, recomiendo dividirlos primero en Subversion; luego, si / cuando te mueves a git, simplemente puedes apuntar git svn a las partes relevantes del repositorio para la conversión.