Si j'essaie de comprendre, ca ressemble à la gestion par composant.
i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
C'est le pendant coté GCL de l'architecture à base de composants http://en.wikipedia.org/wiki/Component-based_software_engine(...)
Ton application est un simple assemblage de plusieurs versions de composants.
Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
On est soit fournisseur, soit consommateur du composant.
Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.
UCM et Clearcase gère ça pas trop mal.
SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals
Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.
[^] # Re: c'est pas franchement grave
Posté par El Titi . En réponse à la dépêche Rififi autour de Subversion. Évalué à 3.
i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
C'est le pendant coté GCL de l'architecture à base de composants
http://en.wikipedia.org/wiki/Component-based_software_engine(...)
Ton application est un simple assemblage de plusieurs versions de composants.
Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
On est soit fournisseur, soit consommateur du composant.
Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.
UCM et Clearcase gère ça pas trop mal.
SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals
Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.
http://stackoverflow.com/questions/2479274/using-mercurial-i(...)