Pratiques standard pour Subversion

Question

Je me demande s'il y a d'autres facteurs à considérer pour la pratique standard d'utilisation de Subversion.

Les rares que j'ai sont:

• structure Répertoire des/tags/tronc et/branches

• Tout le travail est fait dans le coffre qui ne rompt pas la fonctionnalité

• Branch quand des modifications structurelles majeures sont effectuées ou lorsqu'une fonctionnalité est ajoutée qui casse les fonctionnalités de base (sous réserve de préférence)

• Mots clés contient les versions stables

• Toujours effectuer une mise à jour avant de commencer le travail

• livrez des changements à la fin de la journée/lorsqu'une fonction a été ajoutée

• Commit notes contiennent une description pertinente

• Valider sur la base de la fonctionnalité - Ne pas valider la couverture

Je suis dans les esprits conflictuels sur la règle de commettre à la fin de la journée et quand une fonctionnalité a été ajoutée. Je dis à la fin de la journée que le référentiel est le plus à jour possible. Cependant, le code à la fin de la journée peut être incomplet ou interrompre la fonctionnalité. Cependant, le fait de ne valider que lorsque les fonctionnalités ont été complétées peut causer des problèmes/conflits?

J'apprécierais votre critique sur n'importe laquelle de mes idées et de vos idées que j'ai manqué.

Merci!

Answer 1

Vous devriez toujours faire une mise à jour avant de commettre, pour éviter d'éventuels conflits avec d'autres commits faits par d'autres personnes et des fusions douloureuses.

En outre, chaque validation doit contenir quelque chose de significatif, comme une correction de bogue, une nouvelle fonctionnalité ou une amélioration par rapport à une fonctionnalité existante, quelque chose de significatif pouvant être décrit dans le message de journal. Un outil de contrôle de source n'étant pas un outil de sauvegarde, la validation «en fin de journée» sans contenu significatif doit être évitée.

Answer 2

Si vous êtes nouveau à SVN alors une bonne ressource (gratuite) est la SVN Book (les copies d'arbre mort peuvent aussi être achetées chez O'Reilly).

Answer 3

"Cependant, le fait de ne valider que lorsque les fonctionnalités ont été complétées peut causer des problèmes/conflits?"

Si le changement est si important que vous vous inquiétez à ce sujet, alors vous devriez probablement avoir ramifié. Cela vous permettrait de faire de plus petits commits si le travail incrémental sans casser la construction, et laisser un historique clair après la fusion dans le tronc.

Answer 4

Si une « fonction », il faudra plus de quelques (4-6) heures pour terminer, je voudrais soit

• diviser la « caractéristique » en sous-tâches qui peuvent être réalisées en quelques heures et cochés dans le contrôle source
• créer une branche
• deux ci-dessus

Answer 5

Il y a beaucoup de variations en ce qui concerne les flux de contrôle de code source. Celui que nous utilisons est l'extension de ce que vous décrivez dans votre message. Votre flux de travail est suffisant pour des modifications mineures, mais pas si plusieurs équipes travaillent sur des problèmes complexes. Ce que nous faisons est de ramifier pour chaque équipe, que l'équipe peut s'engager dans la branche d'équipe (projet). Chaque équipe est également responsable de la synchronisation de la branche de l'équipe avec le tronc en fusionnant le tronc à la branche, de préférence après chaque validation du tronc. Une fois le projet terminé, la branche est fusionnée en réseau (réintégré) et supprimée.

Cette branche d'approche - fusionner ... fusionner - fusionner en arrière - supprimer fonctionne bien pour nous

Answer 6

Je vais essayer de commettre aussi souvent que possible. Pour permettre ceci, vous devez vous assurer que le code que vous écrivez n'est pas encore utilisé, ou est tel que tous les tests passent. Si vous restez dans l'un de ces deux modes (ce dernier étant beaucoup mieux que l'ancien), vous ne devriez pas avoir à vous soucier de ces grandes périodes où vous ne pouvez pas commettre.

TDD aide beaucoup à cet égard.

Answer 7

Les branches sont une bonne idée pour faire de grands changements, éventuellement cassants. Si le tronc est mis à jour en même temps, fusionnez occasionnellement le tronc à la branche pour maintenir la branche à jour.

Validez un ensemble atomique de modifications connexes. Ne faites pas un grand engagement avec des changements sans rapport. Cela rend le suivi des modifications spécifiques beaucoup plus facile.

Vous pouvez avoir plusieurs extractions de la même source - utile si vous expérimentez avec des modifications sans rapport.

Évitez de valider du code interrompu ou du code avec des tests défaillants ou d'autres problèmes en suspens.

Answer 8

Quelques autres notes: (ont essayé de ne pas répéter ce qui a déjà été dit ..)

Branches:

1. En plus de branchement pour les gros morceaux de développement de fonctionnalités mentionnées ci-dessus, vous pouvez faire une branche lorsque vous devez travailler sur des correctifs postérieurs à la publication, alors que le travail parallèle progresse sur la ligne principale/le tronc.

2. Inverser fusionner régulièrement si vous utilisez des branches qui vivent longtemps sans être fusionné au développement de la ligne principale. Cela aidera à rester en phase avec le développement du tronc et minimiser les complications d'une fusion Big Bang.

3. Faites attention à la façon dont vous nommez vos branches. Nous essayons de nommer les branches après le jalon. Il est utile lorsque vous avez besoin de différences ou de rapports rapides, ou même lorsque vous cherchez quelque chose, si les noms sont explicites.Comme dans SVN la branche est une copie bon marché, nous essayons toujours de nous ramifier à la racine du répertoire du projet (si c'est le tronc du dossier lui-même, alors la branche sera hors tronc) - ceci évite plus tard la confusion qui a dérivé d'où et évite d'avoir à exécuter des commandes pour le découvrir. Et si vous avez besoin d'acheter des trucs à partir d'une branche everythign sous la branche est disponible pour vous --- si vous en avez besoin.

engage à:

1. Je vote pour engage souvent et en morceaux logiques afin de pouvoir lier les fichiers liés par un message commun commettras. C'est génial pour quand vous voulez un journal et le rapport est fait en morceaux avec le tas de fichiers tout attachés soigneusement avec des commentaires pertinents.

2. Je vote pour des engagements fréquents, si ce n'est pas tous les jours. C'est un état d'esprit. Une fois que vous voyez les avantages d'avoir des commits tôt (bien sûr après que les développeurs ont vérifié les erreurs de compilation de base et ont exécuté des tests unitaires dans leur boîte de dev), vous seriez heureux d'attraper ces bogues/problèmes de construction. Si vous envisagez d'exécuter des versions nocturnes ou d'utiliser un outil d'intégration continue, vous feriez mieux d'inciter les gens à s'engager le plus tôt possible pour vous aider à comprendre les flux de travail intégrés et à exécuter des tests sur eux.

Tags:

1. Clouer les conventions de nommage de presse - même si cela semble trivial, il est utile d'avoir de bons noms de balises. Assurez-vous également que les commentaires de validation pour les balises spécifient exactement la raison pour laquelle vous étiquetez cette version du référentiel. Nous ne marquons que lorsque nous réalisons des jalons, donc dans notre cas, nous mappons les messages de validation de tag avec le numéro de build continu (tag de build de croisière) que nous utilisons pour la build donnée. Il est également utile d'avoir le schéma de numérotation des versions et les champs définis afin que vous puissiez les utiliser pour les tags.

Answer 9

J'ai récemment participé à l'amélioration des techniques de gestion de la configuration logicielle (SCM) utilisées dans l'entreprise pour laquelle je travaille. Nous avons constaté que le «branchement pour le développement» et le «branchement pour la libération» fonctionnent plutôt bien. Un bon livre sur les modèles SCM/procédures standard que j'ai trouvé utile est "Patterns de gestion de la configuration logicielle: travail d'équipe efficace, intégration pratique par Berczuk et Appleton".