Contenu | Rechercher | Menus

Annonce

Ubuntu-fr vend de superbes t-shirts et de belles clés USB 32Go
Rendez-vous sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 24/07/2016, à 15:40

Elzen

Organisation / gestion de version pour projet composé

Plop les gens o/

Je bosse actuellement sur un projet constitué de quelques applis conçues pour fonctionner ensemble, mais indépendantes les unes des autres (principes Uɴɪx, tout ça).
En gros, j'ai :

  • Quelques fichiers ressources communs (licence, etc.)

  • Un jeu de bibliothèques contenant le code commun aux différentes applis

  • Quelques fichiers ressources spécifiques à chaque appli (conf' de base…)

  • Les bibliothèques et exécutables contenant le code spécifiques à chaque appli

Ce qui, jusque là, me semble relativement normal.

Le souci, c'est que j'ai beaucoup de mal à trouver un moyen d'organiser tout ça. J'm'explique.
Comme chaque appli est conçue pour pouvoir fonctionner de manière indépendante, j'aimerais faire en sorte qu'il soit possible de n'en récupérer qu'une, sans devoir se manger l'intégralité du projet dont une bonne partie des commits concerneraient autre chose. Pour autant, je préférerais ne pas avoir à gérer ça comme étant plusieurs dépôts séparés, dans la mesure où une partie du code est commun et où, chaque modification impactante des biblis communes (du genre, rectifier le synopsis d'une fonction, donc modifier les fichiers qui l'appellent) signifierait aller commiter quinze projets différentes, ce qui est assez lassant (en plus de casser l'atomicité des commits).

En gros, le cas d'utilisation que je vise :

  • Un dev qui veut bosser sur l'ensemble du truc (par exemple, moi) clone le dépôt entier, et peut travailler sur tout d'un coup sans avoir besoin de jongler avec plusieurs versionnages différents.

  • Un utilisateur intéressé par seulement une des applis peut récupérer seulement celle-là (sans avoir à aller chercher manuellement les biblis qui vont bien, sinon ç'pas pratique), et peut mettre ça à jour en suivant les MàJ du dépôt principal.

  • Un dev intéressé par seulement une des applis peut faire la même chose, et si possible contribuer sans avoir besoin de se manger l'entièreté du dépôt non plus (et pour un dev, la solution de packager dans un PPA dédié ne marche pas).

Et on dirait qu'aucun gestionnaire de version actuel ne prends en compte ce genre de trucs.
SVN permet de ne récupérer qu'un sous-répertoire du projet global, aussi bien pour utiliser que pour contribuer, mais le côté centralisé est quand même vachement peu pratique à l'utilisation, notamment pour commiter des trucs quand je n'ai pas accès à Internet; or les trucs décentralisés que j'ai tenté (Git, Darcs, plus rapidement Mercurial, Bazaar et Fossil) n'ont pas l'air de proposer cette fonctionnalité de façon simple.
De plus, ça nécessite de faire en sorte qu'il y ait un répertoire pour chaque appli, contenant notamment les biblis communes utilisées par l'appli en question. Qui doivent donc se trouver dans le répertoire de chacune des applis concernées, ce qui nécessite de faire des liens. Et pour aucun des gestionnaires de version, je n'ai vu de moyens simple d'indiquer « ces deux fichiers-là, c'est le même, en fait ».
Or, je ne vois pas comment ce serait possible d'organiser les choses différemment (les fichiers à une place unique à chaque fois pour éviter les soucis de lien) sans rendre la récupération d'une partie seulement du projet beaucoup moins gérable.

Donc je n'sais pas trop comment organiser ça, ce qui m'embête un peu.
Z'auriez des idées ?

(Ah, au fait, une précision supplémentaire : ça me semblerait bien que le truc puisse être mis à disposition autre part si quelqu'un veut s'en charger, mais dans l'idée, le dépôt principal doit pouvoir tourner sur mon serveur, évidemment)

Hors ligne

#2 Le 24/07/2016, à 22:03

claudius01

Re : Organisation / gestion de version pour projet composé

Bonsoir,

Ma réponse sera inversement proportionnelle à tes explications et soucis...

Si SVN et autres Gestionnaires de Versions que tu cites ne te satisfont pas, je crains que tu doives en réinventer un autre ;-).

Plus sérieusement, remet toi en cause et organise ton projet qui est pour moi plusieurs projets avec des interdépendances qui peuvent se décliner en autant de repositories depuis lesquels chaque développeur pourra "piocher" sans devoir "descendre" la totalité desdits projets, chose qui n'est effectivement pas souhaitable et dans la mesure où chaque projet propose en final des livrables directement utilisables...

Dernière modification par claudius01 (Le 24/07/2016, à 22:36)

Hors ligne

#3 Le 25/07/2016, à 00:02

Elzen

Re : Organisation / gestion de version pour projet composé

Je ne sais pas si tu sais, mais, quand quelqu'un expose une situation qu'iel a tournée et retournée dans sa tête pendant un moment avant de se décider à poster, c'est assez désagréable de lire des réponses qui commencent par un « remet-toi en cause » tout sauf approprié… d'autant plus quand la suite incite à s'organiser différemment (sans tellement plus de précision), alors que précisément, la question posée porte sur la façon de s'organiser.

Sinon, entre temps, j'ai fais circuler le post d'ouverture de ce sujet, et j'ai eu quelques réponses un peu plus pertinentes sur IRC. En particulier, captnfab de Debian Facile (pour rendre à César ce qui lui appartient) m'a suggéré de jeter un œil à l'outil mr, qui permet de gérer plusieurs dépôts d'un coup.
Avec un dépôt git principal contenant les quelques fichiers communs principaux, dont un fichier .mrconfig contenant les adresses des différents dépôts secondaires et un script qui va gérer quelques détails, du type refaire des liens entre fichiers là où il y en a besoin, et le reste dans lesdits dépôts git secondaires, mais où une seule commande permet de tout commiter d'un coup, ça a l'air de se rapprocher pas mal de ce que je voulais smile
(J'eus préféré pouvoir avoir un historique commun pour pas mal de raisons ; mais plusieurs historiques différents qu'on peut manipuler comme si c'en était un seul, c'est déjà mieux que rien).

Je joue un peu avec pour voir ce que ça donne, et, si tout se passe bien, je passerai ce sujet en résolu d'ici peu.

Hors ligne

#4 Le 27/07/2016, à 19:57

ssdg

Re : Organisation / gestion de version pour projet composé

Un peu de contexte: je suis dev java sur un projet comprenant plusieurs applis web ( déployées ensembles mais indépendantes) qui partagent des libs et des composants communs. Je trouve que c'est plutôt proche.

Chez nous, on a un gros dépôt git commun. (Donc un historique) et un projet maven par projet et librairies. Les projets maven dans ton cas seraient des makefiles ou des scripts et en fonction de la tâche que tu lance, cela compilera le logiciel que tu veux (ou tous) et ses dépendances. ( Mais pas le reste).

Du coup, oui, tu récupères tout le dépôt (mais le code ça ne pèse pas lourd) mais tu ne compile et doit comprendre que ce que tu veux.


s'il n'y a pas de solution, c'est qu'il n'y a pas de problème... ou pas.

Hors ligne

#5 Le 14/08/2016, à 08:30

JBF

Re : Organisation / gestion de version pour projet composé

Est-ce vraiment si gênant que ça de récupérer l'ensemble du projet pour ne travailler que sur une partie ? Si ça en simplifie la gestion, ça en vaut peut-être la peine. Comme dit par ssdg le code ne prend pas beaucoup de place.


LibreOffice : https://fr.libreoffice.org/ (téléchargement, documentation, FAQ, assistance, contribuer, ...)
Aide pour LibreOffice par la communauté francophone : https://ask.libreoffice.org/fr/

Hors ligne

#6 Le 18/08/2016, à 14:14

Nairwolf

Re : Organisation / gestion de version pour projet composé

Je vais essayer de te donner mon point de vue, sans prétendre que c'est la vérité absolu, d'autant plus que je ne sais pas exactement ce que c'est ton code, si la façon dont tu t'organises est la bonne ou pas.

Elzen a écrit :

Comme chaque appli est conçue pour pouvoir fonctionner de manière indépendante

Si vraiment tes applis sont censé fonctionner de manière indépendantes, si je peux en prendre une et une seule, et me satisfaire de cela, et vivre ma vie sans me soucier du reste, alors, je pense qu'il faudrait séparer le code et avoir des repository pour chacune de ces applications. Si je m'intéresse à l'appli A uniquement, je me fiche de savoir comment évoluent B et C.

Cela implique aussi que tu développes tes applis de manière générique et universel. C'est une sorte de librairie utilisable par quiconque, et pas uniquement par ton projet global qui en utilisent plusieurs d'entre elles. En gros, ce que tu fais, c'est développer plusieurs librairies qui ont un but différent, et tu développes en plus, une autre application qui a pour dépendance ces librairies là.

Si c'est bien cela ce que tu fais, alors, il faut séparer les repository. Si par contre, il y a des dépendances et une orientation commune, c'est différent. Dans le dépot de Linux, je pense qu'il y a des sous-parties qui n'ont strictement rien à voir les unes des autres. Pourtant, tout est regroupé ensemble car il y a un but commun.

Sinon, Git a la possibilité d'avoir des sous-modules. Je ne sais pas si cela correspond bien à ton besoin car je n'ai jamais utilisé cela. Il serait peut-être bien de consulter la doc et se renseigner sur ça : https://git-scm.com/book/en/v2/Git-Tools-Submodules

Hors ligne