Supongamos (por simplicidad) que tenemos una aplicación con cliente y servidor; ¿Hay una mejor idea de usar un repositorio para ambos o un par de repositorios separados?
Mezclarlos probablemente facilitará el seguimiento de los cambios correlacionados y mantendrá las ramas correlacionadas (es decir, la evolución del protocolo), pero por otro lado hará que el desarrollo individual sea más desordenado ...
Si está utilizando git o mercurial , entonces es posible que desee ver submódulos o subrepositories .
El cliente, el servidor y sus archivos de interfaz estarían en sus propios repositorios, pero estarían unidos en el nivel super-repositorio . Esto le permitiría hacer una verificación en el nivel superior y git o hg verificarían la confirmación apropiada de cada uno de los submódulos / subrepositorios.
Al comprometerse solo con el súper repositorio cuando tanto el cliente como el servidor eran apropiados entre sí, el súper repositorio solo le daría la opción de verificar un sistema que funcione, por lo que nunca intentará ejecutar el nuevo cliente contra un servidor antiguo o viceversa.
Los submódulos / subrepositorios le brindan todas las ventajas de usar repositorios separados, junto con las ventajas de un solo repositorio monolítico, a costa de una pequeña complejidad adicional.
Esta respuesta no pretende abogar por git o hg sobre otros SCMs, solo sucede que solo conozco a estos SCM lo suficientemente bien como para saber que existe esta opción . No entiendo cómo funcionan svn externals, por ejemplo.
Separate!
De hecho, probablemente tendría tres repositorios, uno para el Cliente y las bibliotecas correspondientes solo para el cliente, uno para el Servidor (y las bibliotecas correspondientes), y uno para las bibliotecas compartidas (incorporando las interfaces API que exponen la funcionalidad entre los dos, más cualquier otro código compartido). Creo que esa es realmente la clave, el código compartido debe ir a un repositorio separado. De esa manera, puede asegurarse de que la interoperabilidad entre su cliente y el servidor se encuentre siempre en la misma versión Y esté aislada del diseño de cada uno de sus consumidores.
Obviamente, esto no siempre es posible, dependiendo del marco de comunicación en particular que esté utilizando, pero es probable que haya un código compartido que dicte el formato de los objetos de transferencia de datos o los pasos del protocolo de enlace en su protocolo personalizado (o algunos otro ejemplo).
Suponiendo que tiene una Integración continua y una configuración de control de calidad bastante decentes (una suposición bastante amplia, según mi experiencia, pero que voy a realizar de todos modos. Si no tiene un departamento de control de calidad, al menos debería obtener un IC ) no debería necesitar usar el patrón de repo único como una defensa contra posibles errores de coincidencia de código, ya sea su servidor de CI marcará la interoperabilidad de la biblioteca o su equipo de control de calidad detectará errores de tiempo de ejecución (o, mejor aún, sus Pruebas de unidad será).
Los beneficios de los repositorios divididos se encuentran en la capacidad de crear versiones separadas de partes de un sistema por separado. ¿Desea tomar una copia del Servidor de la semana pasada y ejecutarlo con el Cliente de esta semana para intentar bloquear la raíz de un problema de rendimiento? No te preocupes.
En Mercurial , este esquema se puede usar, usando -> para denotar una relación de subrepo:
product -> client -|-> (many components)
|-> shared component A
-> server -|-> (many components)
|-> shared component A
El producto tiene subrepos cliente, servidor. Cada uno de ellos tiene sus componentes como subrepos, posiblemente al menos un subrepo compartido entre los dos.
El etiquetado probablemente debería hacerse en los primeros dos niveles, no por debajo de eso.
Los compromisos se realizan en el nivel de componente, los superpospos rastrean de manera efectiva las sucursales y versiones nombradas del producto. Las ramas / marcadores con nombre generalmente son mejores que las ramas clónicas para la facilidad de uso (es decir, capacidad de entrenamiento) y la compatibilidad con subposiciones.
hg tiende a suponer que las superposiciones son el producto, y las confirmaciones se realizan en el nivel superior, pero eso no funciona especialmente cuando varios productos usan los mismos componentes. :-)
No creo que este esquema cambie mucho si se hace la transición a git, pero aún no lo he probado en git.
Este es un problema de administración de la configuración, no un problema de control de revisión. Como siempre, un programador usa un destornillador para clavar un clavo. Calcule cómo administrará sus configuraciones, el control de revisión se hará cargo de sí mismo.
El enfoque más simple es usar un solo repositorio, por lo tanto, a menos que te guste la complejidad por su complejidad, entonces esa debería ser la opción predeterminada en ausencia de argumentos convincentes.
¿El desarrollo del cliente y del servidor será llevado a cabo por diferentes organizaciones? ¿Habrá múltiples implementaciones del cliente (o servidor)? ¿El código abierto del cliente y la implementación del servidor son secretos? Si la respuesta a todas estas preguntas es "No", es probable que cualquier cosa más compleja que un solo repositorio solo genere inconvenientes sin beneficio.
Si elige mantener bases de código separadas, necesitará políticas claras sobre cómo se administra esto, a fin de evitar incompatibilidades y el infierno de la dependencia. Después de superar los primeros contratiempos, podría terminar descubriendo que lo más seguro es que siempre comprueben ambos repositorios juntos, los construyan juntos y los implementen juntos ... ¡lo que obviamente anula todo el propósito de separarlos!
La modularidad es una buena propiedad, pero dividir los repositorios no es una herramienta para lograrlo. Como lo indica el párrafo anterior, puede tener componentes altamente acoplados que se dividen en múltiples bases de códigos (no deseables), y también puede tener componentes altamente modulares dentro de la misma base de códigos (deseable).
En más de una ocasión, he recomendado (con éxito) que mi equipo fusione los repositorios de git existentes, porque simplificó el desarrollo y la implementación.
Olvídate del repositorio por un momento. ¿Cómo organizaría los dos proyectos en su máquina si no estuviera compartiendo con nadie? ¿Cómo lo haría el resto del equipo? ¿Te gustaría ...
¿Poner todos los archivos de origen para el cliente y el servidor en el mismo directorio?
¿Crear un directorio principal del proyecto que contenga subdirectorios para el cliente y el servidor?
¿Mantener los dos proyectos completamente separados?
Una vez que llegue a un consenso sobre eso como equipo, estará listo para registrar los proyectos en su repositorio de código. Todas las herramientas de control de revisiones en las que puedo pensar están felices de reproducir cualquier estructura de directorios que le guste, no les importa en absoluto qué archivo pertenece a qué proyecto. Y la diferencia entre tener un repositorio o dos (o seis) no suele ser tan grande, aparte de pequeñas diferencias administrativas.
Por ejemplo, con Subversion, la mayor diferencia entre repositorios separados para el cliente y el servidor y un solo repositorio combinado está en la forma en que cambian los números de revisión. Con un repositorio único, el número de versión aumentará cada vez que confirme el código a un cliente o servidor. Con repositorios separados, un compromiso con el proyecto del servidor no cambiará el número de revisión principal para el cliente.
Lea otras preguntas en las etiquetas version-control