Discussion :

[dorian833]

Bonjour,

Cela fait quelques jours que je réfléchi pour mettre en place une solution fiable et propre pour la gestion de source multi-projets axés autour d’une même librairie et je souhaiterais avoir votre avis sur la question et savoir si je fais fausse route sur la solution envisagée.

Voici le contexte : Nous avons plusieurs projets (généralement entre 2 et 4) développés en parallèles par différentes équipes (de 1 à 6 personnes selon les projets) qui se basent sur la librairie, développée en interne et qui évolue au fur et à mesure des besoins des différents projets. Ces projets possèdent une base commune en plus de la librairie et diffèrent généralement par des plugins et des ressources spécifiques. La plupart des modifications effectuées (évolutions, résolutions de bugs, …) lors du développement d’un projet sont généralement réalisées directement sur les sources de la librairie car potentiellement utiles pour d’autres projets (en cours ou avenir). Sachant que la mise à disposition d'une nouvelle fonctionnalité issue d'un projet n'a pas besoin d'être instantanément disponible pour tout les autres projets et peut donc attendre un point stable du projet source avant son intégration dans le dépôt générique.

Actuellement, les deux projets en cours se trouvent sur le même dépôt Git ce qui a pour côté positif la mise en commun « instantanée » des évolutions sur la librairie et les parties communes des projets. Mais également, un nombre de problèmes grandissant :
- Taille du dépôt grossissant dangereusement (plus de 10Go pour le seul répertoire .git)
- Maintenance moins aisée
- Criticité d’un crash du dépôt central contenant tous les projets, par exemple : actuellement le dépôt central n’est plus clonable suite à un vieux commit/push qui a planté (bluescreen de la machine en pleine opération ) mais détecté trop tard pour pouvoir faire une réparation « simple »
- …

Mon idée est de passer à un dépôt par projet tout en gardant un moyen « simple » de fusionner les évolutions sur la librairie commune. Et par la même occasion passer à un workflow de type Git-Flow qui me semble adapté à notre besoin et devrait simplifier pas mal de problèmes actuels.

Les deux solutions que j’ai trouvées durant mes recherches sont les sous-modules et les subtrees.

J’ai eu l’occasion de pouvoir tester la solution des sous-modules sur un projet « témoin » (sur 4 mois avec deux développeurs) mais semble plus adaptée à la gestion de librairies tierces (évoluant peu) qu’à notre besoin. C’est également l’avis que j’avais pu lire sur plusieurs articles sur cette solution. Voici les principaux problèmes rencontrés :
- Source d’erreur (faute d’inattention du développeur) dans la gestion des branches donc peu adapté à Git-Flow
- La plupart des commits concernent la librairie et entraine un commit « vide » du projet pour « lié » l’état de la librairie
- La lisibilité de l’historique d’un projet est nettement plus compliquée vu qu’il faut prendre en compte l’historique de plusieurs dépôts

Bref, je ne donne que quelques jours à cette solution avant d’être rejetée par le reste de l’équipe surtout sur de plus gros projets avec plus de développeurs et de retourner à la case départ (sans compter la perte de temps pour la mise en place des sous-modules). Ce que je comprendrais parfaitement puisque j’ai moi-même eu régulièrement l’envie de repasser sur un dépôt sans sous-module …

Reste la seconde solution qui me semble plus adapté à notre besoin :
- Une personne par projet aura la responsabilité d’intégrateur au moment de la fusion
- Pour la gestion du dépôt quotidien (commit, …) l’équipe d’un projet pourra travailler sur un dépôt « simple »
- Aucune difficulté pour l’utilisation de Git-Flow
- Lorsqu’un projet est en fin de développement, les évolutions des autres projets ne seront plus intégrées. Ce que je ne vois pas tout à fait comment faire dans le cas des sous-modules.

Le seul point négatif que je vois est l’obligation de passer par des lignes de commandes. Mais qui devrait pouvoir être contourné par la rédaction d’un guide d’intégration propre à notre situation.

L’idée serait alors d’avoir un dépôt central complet d’un « projet générique » qui servirait :
- De base pour tout nouveau projet.
- De cible pour les intégrateurs lors les fusions
- De projet de validation et d’exemple d’usage pour les nouvelles fonctionnalités

Je souhaiterais donc avoir vos avis sur la question sachant que je suis certain que l’utilisation des sous-modules ne sera pas tolérée très longtemps vu les potentielles complications et que la solution actuel du dépôt unique pour tous les projets ne pourra pas tenir très longtemps. Il y a-t-il une solution plus adaptée que les subtrees ?

Merci d’avance pour vos réponses et d’avoir pris le temps de lire le post.

[Philippe Bastiani]

Oui, la mécanique des sous-modules est, IMHO, trop contraignante...

git-subtree est une piste à explorer si tu souhaitess (ce que j'imagine) concerver ton historique ! Mais attention, tu ne vas pas pas faire une cure d'amaigrissement a tes dépots...

Meilleurs voeux,
Philippe

[dorian833]

Merci pour ta réponse et meilleurs voeux également. Elle confirme ce que je pensais à propos des sous-modules.

Mais attention, tu ne vas pas pas faire une cure d'amaigrissement a tes dépots...

Par contre j’aurais cru à une légère amélioration de la taille des dépôts au moins par le suivi des ressources spécifiques à un projet uniquement dans son dépôt.

L’une des raisons de la taille du dépôt est lié au fait que les contribs (2Go actuellement) sont également présentes dans le dépôt, contenu complet des zips de sources ainsi que la version compilée. Cela dans le but d’avoir dès le clone du dépôt les contribs prêtes à l’emploi. Mais il serait sûrement plus logique de conserver uniquement le contenu des packages sources avec une solution de build à exécuter après le clone ou une mise à jour des contribs. Surtout que le nombre de binaires compilés risque d’augmenter entre l’ajout de nouvelles contribs, configuration de cibles supplémentaires, …

Les contribs pourraient être gérées dans un sous-module partagés entre les dépôts projet mais il y a du coup un gros risque d’avoir un moment donné un manque de cohérence en cas d’évolution de celles-ci dans un projet mais pas encore répercutée dans les autres projets. De plus le rôle d’intégrateur serait également biaisé puisque n’importe quel développeur pourrait agir sur le dépôt « générique ».

[Philippe Bastiani]

Le problème c'est que tu gardes tout l'historique lors de ton split.

Après pour chaque dépôt tu dois pouvoir faire le ménage (i.e. supprimer définitivement (et non pas un simple remove) certains objets

Après pour la gestion multi-dépôts il va te falloir une gestion de dépendances => le mieux est de passer par un outil (il en existe même pour PHP) - Donc tout dépend de ton environnement de dev.
Dans tous les cas il sera bon d'avoir une gestion des versions cohérentes en dev->integration (git-flow pourra t'aider). Cela comprend aussi une gestion des numéros de version (qui pourrait augmenter à chaque push, etc...).

a+
Philippe

[dorian833]

Le problème c'est que tu gardes tout l'historique lors de ton split.

Si j’ai bien compris ce que j’ai lu, la commande split permet de « générer » un clone de l’historique du dépôt mais en ne contenant que les commits concernant le sous-répertoire spécifié en filtrant seulement les modifications concernant les fichiers dans ce répertoire pour chacun des commits ? Ce qui devrait éliminer toutes les modifications qui ne concerne pas la libraire.

Lors du merge, apparemment il existe l’option « squash » qui devrait permettre une fusion des commits et au moment de finir le merge, il suffirait de faire un listing des modifications apportées dans le message du merge. Cela devrait permettre d’avoir un historique un peu plus propre dans le dépôt générique.

Après pour la gestion multi-dépôts il va te falloir une gestion de dépendances => le mieux est de passer par un outil (il en existe même pour PHP) - Donc tout dépend de ton environnement de dev.
Dans tous les cas il sera bon d'avoir une gestion des versions cohérentes en dev->integration (git-flow pourra t'aider).

Pour l’environnement de développement, c’est simplement du C++ natif édité, configuré et compilé via Visual Studio 2012 sur Windows uniquement. Si tu as un nom d’outil de gestion de dépendances pour du C++ sous Windows, je suis intéressé.

Actuellement même si c’est effectivement assez lourd, la présence des contribs dans le dépôt du projet permet d’avoir une cohérence entre tous les développeurs au sein d’un même projet. Du coup, il n’y a pas de « mise en commun » des fichiers des contribs entre les projets puisqu’elles sont présentes dans un sous-répertoire du projet.

Donc effectivement, à moins de passer par un gestionnaire de dépendances, je ne vois pas trop d’autres solutions que de passer également par les subtrees.

Cela comprend aussi une gestion des numéros de version (qui pourrait augmenter à chaque push, etc...).

Actuellement seuls les projets possèdent un numéro de version mais il serait logique que la librairie possède sa propre numérotation.

[Philippe Bastiani]

L'option squash te sera utile pour bien séparer tes historiques à partir de ton 'git-subtree add --squash ...'. Si tu concerves ton dépots initial il te faudra récurer ton histoque après ton split et tes suppression. Autre soluce : tout splitter et repartir sur un nouveau dépot de base.

Pour la gestion des dépendances et des tes builds en général : SCONS semble pas mal du tout pout C++.

Mais comme dit plus haut : dans tous les cas, il faut organiser tes builds/livraisons dans son ensemble. Si tu ne disposes pas d'un outil de build centralisé, l'option la plus simple : à chaque intégration (partielle ou finale) tu incrémentes toutes tes versions et tu poses un tag commun. En gros, tes sous-projets peuvent vivre leur vie... mais, au moment de l'intégration tu force une sorte de synchro !

a+
Philippe