SVN mise en page - les meilleures pratiques

Question

Dans CVS nous avons sur le projet avec plusieurs répertoires là-dedans. Il y a une nightly build qui doit tirer dans des choses de différents répertoires dans le même projet CVS afin de construire la construction de nuit. Donc, je devrais avoir cela à l'esprit et je dois modifier le script de compilation pour vérifier les choses de différents référentiels si nous passons à SVN.

J'ai lu le QA SVN lié, mais j'ai ma propre question que j'ai besoin pour la réponse.
Je peux le faire:

/trunk
/tags
/branches
/3rdparty

Où tout ce que nous développons sort du / tronc et tout 3rdparty que nous ne changeons pas va / 3rdparty.

Tout bon, maintenant le script nightly build doit marquer le tronc, la caisse de la balise, consultez les trucs 3rdparty nécessaires dans les répertoires appropriés, puis commencer le processus de construction.
Le résultat de la construction (stuff compilé) peut rester sur NFS monter pendant une certaine période si l'équipe d'intégration peut revenir 2 semaines et de recréer des problèmes.
Est-ce toutes mes bases couvertes?

Answer 1

Le SVN Redbook comprend beaucoup d'informations sur les mises en page pour les différents types de projets et comment les gérer .

Vous pouvez également utiliser des crochets / déclencheurs / externes pour importer des données à partir d'un repo indépendant appelé « 3ème partie ». Alors, quand un développeur vérifie un repo, il obtient la 3ème partie aussi. Il y a des tonnes de façons de séparer les préoccupations, mais présenter une prise en pension unifiée de ceux qui le composent.

Bonne chance

Answer 2

Il est peut-être la peine de faire usage d'un moteur de construction comme hudson contrôle ou de croisière. Le flux de travail est légèrement différent - les étiquettes sont faites après la construction, mais vous pouvez obtenir des modules supplémentaires qui vous donnent un certain contrôle sur cela. Point est, tout le travail de dev est fait pour vous, et vous obtenez un cadre décent pour votre nightly builds, et vous obtenez une interface web agréable pour tout contrôler et surveiller.

Personnellement, je mettrais quelques externals sur le tronc pour tirer dans les bibliothèques 3ème partie appropriées dans les endroits appropriés. De cette façon, lorsque vous modifiez 3ème version de la bibliothèque de partie, vous apportez les modifications au tronc et ne pas modifier les scripts de compilation. Cela signifie également que vous pouvez construire des versions plus anciennes être juste vérifier le tronc approprié / tag / branche. Soyez averti - faire juste les sur le tronc, les dispersant autour peut conduire à assassiner

.

Je couche également la prise en pension un peu comme:

project
 /trunk
 /branches
 /tags
3rdparty

Tout simplement parce que cela vous donne plus de possibilités pour ajouter plus de projets de haut niveau à un moment donné. Cela vous permet de gérer différents projets totalement indépendante - et vous pouvez toujours utiliser pour référencer les externals versions d'un droit à l'autre s'il y a des dépendances - ce bien arrête des changements dans un projet de rupture en silence / changement de projets dépendants

.

Il est possible de le faire en utilisant repo séparés aussi bien, ce qui est bien, mais dans ce cas, je mettrais la section séparée 3rdparty dans une pension séparée dès le départ.

Answer 3

Pourquoi ne déplacez-vous pas la 3e partie en tronc? lorsque chaque branche pour vous une copie de la 3e partie va dans la branche. Et, évidemment, vous changez l'habitude des choses 3e parti parce que votre branche branche a Codé en fonction de la 3e substance de partie existante.

Je ne suis pas sûr de ce que vous tagging parlez. Est-ce que le numéro de version que vous voulez dire? S'il est le numéro de version passe à travers ce scénario et étiqueter la construction.

Answer 4

Si les « plusieurs répertoires » sont des composants séparés que vous voulez à la version indépendante, alors vous devriez avoir chacun dans son propre référentiel afin qu'ils puissent être étiquetés séparément. Mais si cela est un projet autonome (à savoir si vous serez généralement marquage et de branchement de tous les composants ensemble), alors vous pouvez probablement mettre tout le code dans le même référentiel.

Vous devriez envisager d'utiliser pour la externals objets tiers.

Answer 5

Mon script vérifie le tronc, modifie les fichiers (ajuste les numéros de version dans les fichiers AssemblyInfo.cs, etc.), les étiquettes alors que. Si vous n'avez pas besoin de modifier les fichiers de quelque façon, le marquage premier serait alors bon aussi bien.

Autre que cela, votre configuration semble bon pour moi au moins.