2010-02-02 4 views
5

Je travaille actuellement sur un projet qui a des composants en Perl, .NET, C/C++ et Java. Ces composants sont liés, mais ne sont pas liés au même calendrier de publication. En raison des exigences très différentes de l'environnement de construction/test, les regrouper dans la même hiérarchie/bin/src/lib/etc/tests est un peu compliqué. Quelles sont les bonnes hiérarchies organisationnelles à utiliser dans le contrôle de la source lorsqu'il s'agit d'un projet de cette nature? Je me penche actuellement vers chaque langue ayant sa propre branche:Organisation d'un projet utilisant plusieurs langues?

repo/projet1/perl/main/...

repo/projet1/.NET/main/...

repo/project1/Java/main/...

Comment votre hiérarchie recommandée changerait-elle si elle avait un calendrier de diffusion lié?

+1

On dirait que vous êtes sur la bonne voie ... –

Répondre

2

Je pense que ce que vous avez exposé est sur la ligne. Si vous libérez le projet dans son ensemble avec tous les composants plutôt que de relâcher séparément chaque composant, je peux utiliser svn: externals pour différencier les emplacements de repo ou des référentiels entièrement différents, puis associer la construction via external avec la dernière version étiquetée compatible d'un composant . Ou si vous utilisez git, utilisez des sous-modules pour faire la même chose. La structure exacte dépend du flux de travail et de la manière dont les composants sont intégrés, mais vous en avez l'idée.

Questions connexes