Administrar el ajuste de Java de una API de C ++ para que la use una GUI de Java: control de versión adecuado

Tenemos un proyecto grande que consiste en lo siguiente:

  • A: código fuente C ++ / bibliotecas
  • B: envoltura de Java y Python de las bibliotecas C ++, utilizando SWIG
  • C: una GUI escrita en Java, que depende de la API / envoltura de Java.

La gente usa el proyecto de todas las maneras posibles:

  • Proyectos C ++ que usan la API C ++
  • Proyectos de Java usando la API de Java
  • Python scripting
  • Scripts de MATLAB (usando la API de Java)
  • a través de la GUI de Java

Actualmente, A, B y C están todos en un único repository de Subversion. Nos estamos moviendo a git / GitHub, por lo que tenemos la oportunidad de reorganizarnos. Estamos pensando en dividir A, B y C en sus propios repositorys. Esto nos plantea algunas preguntas:

  1. ¿Tiene sentido dividir el envoltorio SWIG de Java y Python (es decir, los files de la interfaz (* .i)) en un repository separado?
  2. Actualmente, los files .java generados por SWIG se generan en el tree fuente de la GUI y se rastrean en SVN. Como no queremos rastrear los files generados por la máquina en nuestros repositorys git, ¿cuál es la mejor manera de mantener la dependencia de la GUI en los files .java / .jar generados por SWIG? Considere esto: si un nuevo desarrollador desea build la GUI de Java, no debería necesitar crear A y B desde cero; deberían poder get una copy de C desde la cual puedan build inmediatamente la GUI.
  3. Versiones: cuando todo está en un repository, A, B y C son necesariamente consistentes entre sí. Cuando tenemos repositorys diferentes, la GUI debe funcionar con una versión conocida de la envoltura y la envoltura debe funcionar con una versión conocida de la API de C ++. ¿Cuál es la mejor manera de gestionar esto?

Hemos reflexionado profundamente acerca de cada una de estas preguntas, pero queremos escuchar cómo la comunidad abordaría estos temas. ¿Tal vez el submodule / subtree de Git es parte de la solución a algunos de estos? No hemos usado ninguno de estos y parece que los submodules causan dolor de cabeza a la gente. ¿Alguien tiene historias de éxito con cualquiera de estos?

OK, miré en un problema similar al tuyo (múltiples proyectos que interactúan) y probé el subtree tres posibilidades, los submodules y un único repository simple con múltiples carpetas que contienen las partes individuales. Si hay más / mejores soluciones, no las conozco.

En resumen, fui por un repository único, pero esta podría no ser la mejor solución en su caso, eso depende …

  • El beneficio de los submodules es que permite una administración fácil ya que cada parte es en sí misma un repository. Por lo tanto, las partes individuales solo pueden trabajar en su repository y las otras partes se pueden agregar a partir de versiones binarias pnetworkingefinidas / … (como prefiera). Debe agregar un repository adicional que concatena los repos individuales juntos.
    Esta es la ventaja y la desventaja: cada compromiso en este repository define una configuration en ejecución. Idealmente, los desarrolladores deberán hacer que cada confirmación se realice dos veces, una para el "repository de trabajo" (A a C) y otra para el repository de configuration.
    Por lo tanto, este método podría ser adecuado si desea que las partes de CA sean en su mayoría independientes y no cambien con demasiada frecuencia (eso es solo para nuevas versiones).
  • Debo confesar que no me gustó personalmente el método del subtree . Para mí (personalmente) la syntax parece torpe y el beneficio no es demasiado grande.
    El beneficio es que las modificaciones remotas se pueden get e insert fácilmente, pero se pierde el historial remoto. Por lo tanto, debe evitar interferir con el desarrollo remoto.
    Esta es la desventaja: si tiene la intención de hacer modificaciones en las partes, siempre debe preocuparse por el historial. Por supuesto, puede desarrollar en un control remoto git y para probar / fusionar / integrar el cambio a la twig master . Esto está bien para leer principalmente repos remotos (si estoy desarrollando solo en A pero necesito B y C) pero no para modificaciones regulares (en el ejemplo para A).
  • La última posibilidad es un repository simple con carpetas para cada parte. El beneficio es que no se necesita directamente ninguna administración para mantener las partes sincronizadas. Sin embargo, no podrás garantizar que cada commit sea un commit en ejecución. Además, los desarrolladores tendrán que hacer la administración a mano.

Verá que la elección depende de cuán cerca están conectadas las partes individuales AC. Aquí solo puedo adivinar:
Si se encuentra en una etapa anterior de desarrollo donde las modificaciones en todo el tree de fonts son comunes, un repo grande es mejor manejable que una versión dividida. Si sus interfaces son en su mayoría constantes, la split permite repositorys más pequeños y una separación más estricta de las cosas.
El código SWIG y el código C ++ parecen bastante cercanos. Por lo tanto, dividir esos dos parece less práctico que dividir la GUI del rest (para mi conjetura).

Para ti otra pregunta "¿Cómo manejar nuevos desarrolladores / (un) seguimiento del código generado por la máquina?":
¿Cuántas confirmaciones se realizan / requieren (solo versiones o cada compromiso individual)? Si solo le interesan los lanzamientos, puede ir con packages binarys. Si intenta compartir cada compromiso, debería proporcionar muchas versiones binarias diferentes. Aquí sugeriría que les permitiera comstackr todo el tree una vez que consumen unos minutos y, a partir de ahí, la reconstrucción es solo una pequeña make que no debería llevar demasiado time. Esto incluso podría automatizarse usando ganchos.