Mantenga las partes del proyecto en un repository o divídalas en múltiples

TL; DR ¿Deberían todas las partes del proyecto de tamaño medio estar en un repository o debería cada parte tener un repository propio?

Estoy comenzando un nuevo proyecto en C ++ (pero creo que esto es independiente del idioma), que constará de pocas partes. Servidor, Cliente – Linux (mientras que los clientes también pueden trabajar con p2p), Cliente – Android, …

Probablemente sea compatible con Linux, Windows y Android para clientes, solo Linux de server.

Estoy pensando que será un proyecto de tamaño mediocre. Tener múltiples versiones lanzadas a la vez no es importante para mí, la versión actual (y solo mantenida) será trunk. Aunque usaré funciones y twigs de errores.

Y ahora finalmente a mi pregunta. ¿Debo usar solo un report para todo esto? Puedo imaginarlo simplificando las cosas un poco. Y no estoy comenzando Kernel 2.0, no habrá tantos files (espero).

El entorno de desarrollo será vim & bash & cmake si eso es relevante

Gracias 🙂

Sugeriría que cada parte tenga su propio repository.

Las razones son que el cliente y el server tienen un ciclo de publicación muy diferente. Al principio, cuando el protocolo de comunicación no está estabilizado, ambos cambian más o less al mismo ritmo, y el cambio que se realiza en ellos está altamente correlacionado.

Sin embargo, las cosas cambiarán cuando el protocolo se estabilice. El desarrollo del cliente y el server se vuelven bastante independientes y tendrán su propio objective. Por ejemplo, planea mejorar la interfaz de usuario del cliente, pero haciendo pequeños cambios de código para el performance en el server. Por lo tanto, es posible que tenga muchas confirmaciones rápidas y frecuentes en el server, pero esto no afecta el desarrollo del cliente. Un gráfico de git independiente en cada parte le da una vista clara.

Para los clientes de diferentes plataforms, es muy subjetivo. Si la coinheritance en la interfaz de usuario, la funcionalidad y el performance entre los diferentes clientes es un objective principal, entonces sugeriría un repository para toda la plataforma del cliente. De lo contrario, cada plataforma puede tener su propio repository.

De hecho, como también saben, no existe el bien o el mal. En mi opinión, el factor key es la correlación entre las partes y si tienen ciclos de lanzamiento similares / sincronizados.

Para cualquier tamaño de proyecto que use un patrón de varias partes o de una sola pieza, es más una cuestión de

  • la mantenibilidad
  • la separación y asignación de responsabilidades, derechos y poderes

que el tamaño del proyecto

En su estructura (bastante compleja) estructura de varios repositorys (basada en subtreees) parece una decisión lógica y razonable