Définir les limites en termes de référentiels

Question

Je vais mettre la scène en premier ...

Nous utilisons Subversion et avons actuellement un référentiel principal relativement grand. Je cherche à le décomposer, avec la possibilité de passer à Git à une date ultérieure. La raison en est que a) Git ne peut pas faire de sous-dossiers, donc favorise les petits repo, b) nous pouvons utiliser beaucoup plus de branches (branche par caractéristique).

Nous avons une application Web, ainsi qu'une application d'automatisation Web.

Ils ne dépendent pas directement les uns des autres en termes de code. Mais l'application d'automatisation dépend de l'application Web en termes de conception. Si une modification est apportée à l'application Web, elle risque de casser l'application d'automatisation. Je voudrais les diviser en repo séparés, mais un bon point a été soulevé. C'est pratique de les avoir sous le même repo, donc vous savez qu'à une certaine révision, ils ont tous deux travaillé ensemble. Comprendre cela avec deux repo séparés, avec deux séries de numéros de révision est évidemment assez compliqué. L'autre problème est que nous avons un certain nombre d'applications (pas seulement celles qui dépendent l'une de l'autre, API, etc ...).

Je voulais juste voir les pensées des gens. Si vous avez eu affaire à un tel problème? Pensez-vous qu'ils devraient ou ne devraient pas être divisés etc ... Utilisez-vous une sorte d'outil de déploiement pour suivre les différentes révisions de chaque repo travaillant ensemble etc ...

Answer 1

d'abord, vous créez un clone de votre svn référentiel, vous pouvez ensuite diviser le référentiel git résultant avec git filter-branch.

Pour que les deux projets redeviennent dépendants, utilisez des sous-modules. De cette façon, un référentiel peut être utilisé avec une révision fixe (utile pour les bibliothèques, dans votre cas l'application web)

Answer 2

En termes d'outils, si vous construisez en utilisant Hudson, il garde une trace de l'ensemble des dépôts et des numéros de révision utilisés dans chaque construction pour vous. Vous pouvez marquer de ceci si nécessaire.

Si vous avez un outil qui fonctionne de cette façon, il n'est pas si important de limiter le nombre de numéros de révision que vous suivez. Je le divise comme ceci - 1 nombre peut être suivi manuellement,> 1 a besoin de support d'outil. Mais ils n'ont pas besoin d'être des outils complexes.

Je préfère un référentiel unique, mais ce n'est qu'une préférence personnelle. Il est basé sur un numéro de révision sans ambiguïté, avec plusieurs repos vous avez besoin du repo et du numéro. Les limites de repo sont alors sur les changements de politique (par exemple, celui-ci est utilisé pour le code, celui-ci pour les documents de l'entreprise, celui-ci pour le déploiement, etc.). Git ne fonctionne pas comme ça, donc vous n'avez pas la possibilité d'utiliser un seul repo. Ce n'est pas une mauvaise chose, et la plupart des systèmes (comme Hudson, Redmine) seront heureux de soutenir cela.

Answer 3

Les séparer permet de les sortir indépendamment, avec leurs propres numéros de version, mais comme vous le constatez, le suivi des dépendances peut être difficile. Nous sommes passés d'un build basé sur Ant à maven pour nous aider avec nos dépendances et malgré quelques problèmes de démarrage cela en valait la peine dans l'ensemble. (Nous avons plusieurs applications qui dépendent les unes des autres de manière étrange et merveilleuse.) Le schéma de base que nous suivons est d'utiliser le Apache Portable Runtime's version numbering, qui est un système à trois chiffres où les versions utilisent une convention MAJOR.MINOR.PATCH standard.

En ce qui concerne le processus pour les séparer va, je recommande de les diviser d'abord dans Subversion; alors si/quand vous passez à git, vous pouvez simplement pointer git svn sur les parties pertinentes du référentiel pour la conversion.