Comment utiliser SVN, Branch? Marque? Tronc?

Je faisais un peu de recherche sur Google et je n’arrivais pas à trouver un bon guide pour les débutants sur SVN , et non sur le sens de “comment utiliser les commandes”; Comment contrôler mon code source?

Ce que je voudrais éclaircir, ce sont les sujets suivants:

  • À quelle fréquence vous engagez-vous? Aussi souvent que l’on appuie sur Ctrl + s ?
  • Qu’est-ce qu’une twig et qu’est-ce qu’une étiquette et comment les contrôlez-vous?
  • Qu’est-ce qui se passe dans le SVN? Seul le code source ou partagez-vous d’autres fichiers ici aussi? (Pas considérés comme des fichiers versionnés ..)

Je n’ai aucune idée de la twig et de l’étiquette, donc je ne connais pas le but, mais ma conjecture est que vous téléchargez des trucs dans le tronc et lorsque vous faites une version majeure, vous la déplacez vers la twig? Alors, qu’est-ce qui est considéré comme une construction majeure dans ce cas?

Le livre de subversion est une excellente source d’informations sur les stratégies de mise en page de votre référentiel, de la création de twigs et du marquage.

Voir également:

Continuez-vous le développement dans une twig ou dans le coffre?

Stratégies de twigment

Je me suis posé les mêmes questions lorsque nous avons implémenté Subversion ici – environ 20 développeurs répartis sur 4 à 6 projets. Je n’ai trouvé aucune bonne source avec «la réponse». Voici quelques éléments de l’évolution de notre réponse au cours des trois dernières années:

– commettre aussi souvent qu’il est utile; Notre règle générale est de valider chaque fois que vous avez fait suffisamment de travail pour que ce soit un problème de devoir le refaire si les modifications sont perdues; parfois je commets toutes les 15 minutes environ, d’autres fois il peut y avoir des jours (oui, parfois il me faut une journée pour écrire une ligne de code)

– nous utilisons des twigs, comme l’une de vos réponses précédentes l’a suggéré, pour différents chemins de développement; en ce moment, pour l’un de nos programmes, nous avons 3 twigs actives: 1 pour le développement principal, 1 pour l’effort de parallélisation du programme qui n’est pas encore terminé et 1 pour la révision afin d’utiliser des fichiers d’entrée et de sortie XML;

– nous n’utilisons guère d’étiquettes, même si nous pensons que nous devrions les utiliser pour identifier les rejets à la production;

Pensez au développement en suivant un seul chemin. À un moment donné ou à un stade de développement, le marketing décide de publier la première version du produit, vous placez donc un indicateur dans le chemin intitulé «1» (ou «1.0» ou ce que vous avez). À un autre moment, une shinye étincelle décide de paralléliser le programme, mais décide que cela prendra des semaines et que les gens veulent continuer sur cette voie. Donc, vous construisez une fourche dans le chemin et différentes personnes se promènent sur les différentes fourches.

Les drapeaux sur la route sont appelés «étiquettes» et les fourches sur la route sont celles où les «twigs» se divisent. Parfois aussi, les twigs se regroupent.

– nous mettons tout le matériel nécessaire pour construire un exécutable (ou un système) dans le référentiel; Cela signifie au moins le code source et créer un fichier (ou des fichiers de projet pour Visual Studio). Mais lorsque nous avons des icons, des fichiers de configuration et tout ce qui s’est passé, cela va dans le repository. Une certaine documentation trouve son chemin dans le repo; certainement toute documentation telle que les fichiers d’aide qui pourraient faire partie intégrante du programme, et c’est un endroit utile pour mettre la documentation du développeur.

Nous y avons même mis des exécutables Windows pour nos versions de production, afin de fournir un emplacement unique aux personnes qui recherchent des logiciels – nos versions Linux vont sur un serveur, il n’est donc pas nécessaire de les stocker.

– Nous n’avons pas besoin que le référentiel soit à tout moment capable de fournir une version la plus récente qui soit conçue et exécutée; certains projets fonctionnent de cette façon, d’autres non; La décision incombe au chef de projet et dépend de nombreux facteurs, mais je pense que cela se dissout lorsque des modifications majeures sont apscopes à un programme.

* How often do you commit? As often as one would press ctrl + s? 

Aussi souvent que possible. Le code n’existe pas sauf s’il est sous contrôle de code source 🙂

Les commits fréquents (par la suite, de petits ensembles de modifications) vous permettent d’intégrer facilement vos modifications et d’augmenter les chances de ne pas casser quelque chose.

D’autres personnes ont noté que vous devez vous engager lorsque vous avez un morceau de code fonctionnel, mais je trouve utile de le faire plus souvent. Quelques fois, j’ai remarqué que j’utilisais le contrôle de source comme mécanisme rapide d’annulation / rétablissement.

Lorsque je travaille sur ma propre twig, je préfère commettre autant que possible (littéralement aussi souvent que j’appuie sur Ctrl + S).

 * What is a Branch and what is a Tag and how do you control them? 

Lire un livre SVN – c’est un endroit où vous devez commencer lorsque vous apprenez SVN:

  • Qu’est-ce qu’une twig?
  • Mots clés
 * What goes into the SVN? 

La documentation, les petits fichiers binarys requirejs pour la construction et d’autres éléments utiles pour le contrôle des sources.

Voici quelques ressources sur la fréquence de validation, les messages de validation, la structure du projet, ce qu’il faut mettre sous contrôle des sources et d’autres directives générales:

  • Meilleures pratiques de contrôle de version (mon propre blog)
  • Check in Early, Check-In souvent (Codage Horreur) (les commentaires contiennent beaucoup de bons conseils)
  • La politique de validation de KDE

Ces questions sur le débordement de la stack contiennent également des informations utiles pouvant présenter un intérêt:

  • Organisation du code source lors du mixage de plusieurs langues (comme Java et C ++)
  • Suggestions pour un bon message de validation: format / guide?
  • À quelle fréquence commettre des modifications au contrôle de source?
  • Apprentissage du contrôle de version et apprentissage

En ce qui concerne les concepts de base de Subversion tels que la création de twigs et le marquage, je pense que cela est très bien expliqué dans le livre Subversion .

Comme vous pouvez vous en rendre compte après avoir lu un peu plus sur le sujet, les opinions des gens sur les meilleures pratiques dans ce domaine sont souvent différentes et parfois contradictoires. Je pense que la meilleure option pour vous est de lire ce que font les autres et de choisir les directives et les pratiques qui vous semblent les plus pertinentes.

Je ne pense pas que ce soit une bonne idée d’adopter une pratique si vous n’en comprenez pas le but ou si vous n’êtes pas d’accord avec la raison d’être. Donc, ne suivez aucun conseil à l’aveuglette, mais prenez plutôt votre propre décision sur ce qui, selon vous, fonctionnera le mieux pour vous. En outre, expérimenter différentes façons de faire est un bon moyen d’apprendre et de découvrir comment vous aimez travailler. Un bon exemple de ceci est la façon dont vous structurez le référentiel. Il n’y a pas de bonne ou de mauvaise façon de le faire, et il est souvent difficile de savoir dans quel sens vous préférez jusqu’à ce que vous les ayez réellement essayées dans la pratique.

La fréquence de validation dépend de votre style de gestion de projet. Beaucoup de gens s’abstiennent de commettre si cela va casser la construction (ou la fonctionnalité).

Les twigs peuvent être utilisées de deux manières différentes, généralement: 1) une twig active pour le développement (et la ligne réseau rest stable), ou 2) des twigs pour des chemins de développement alternatifs.

Les balises sont généralement utilisées pour identifier les versions, elles ne sont donc pas perdues dans le mix. La définition de ‘release’ est à vous.

Je pense que le principal problème est que l’image mentale du contrôle de la source est confuse. Nous avons généralement des troncs et des twigs, mais ensuite nous obtenons des idées sans rapport avec les tags / releases ou quelque chose à cet effet.

Si vous utilisez l’idée d’un arbre plus complètement, cela devient plus clair, du moins pour moi.

Nous obtenons le tronc -> twigs des formes -> produire des fruits (étiquettes / versions).

L’idée étant que vous développiez le projet à partir d’un tronc, qui crée alors des twigs une fois que le tronc est suffisamment stable pour contenir la twig. Ensuite, lorsque la twig a produit un fruit, vous l’arrachez de la twig et le libérez comme une étiquette.

Les tags sont essentiellement des livrables. Alors que le tronc et les twigs les produisent.

Comme d’autres l’ont dit, le livre SVN est le meilleur endroit pour commencer et une référence incontournable une fois que vous avez pris votre pied marin. Maintenant, à vos questions …

À quelle fréquence vous engagez-vous? Aussi souvent qu’on appuierait sur ctrl + s?

Souvent, mais pas aussi souvent que vous appuyez sur ctrl + s. C’est une question de goût personnel et / ou de politique d’équipe. Personnellement, je dirais commettre lorsque vous complétez un morceau de code fonctionnel, aussi petit soit-il.

Qu’est-ce qu’une twig et qu’est-ce qu’une étiquette et comment les contrôlez-vous?

Premièrement, le tronc est votre développement actif. C’est la ligne principale de votre code. Une twig est une déviation de la ligne principale. Cela peut être une déviation majeure, comme une version précédente, ou juste une modification mineure que vous souhaitez essayer. Une balise est un instantané de votre code. C’est un moyen de joindre une étiquette ou un signet à une révision particulière.

Il convient également de mentionner que dans la subversion, le tronc, les twigs et les balises ne sont que des conventions. Rien ne vous empêche de travailler dans des balises ou d’avoir des twigs qui sont votre ligne principale, ou de ne pas tenir compte du schéma de balise-twig-ensemble. Mais, à moins d’avoir une très bonne raison, il est préférable de respecter la convention.

Qu’est-ce qui se passe dans le SVN? Seul le code source ou partagez-vous d’autres fichiers ici aussi?

Aussi un choix personnel ou d’équipe. Je préfère conserver tout élément lié à la construction dans mon référentiel. Cela inclut les fichiers de configuration, les scripts de génération, les fichiers multimédias associés, les documents, etc. Vous ne devez pas archiver les fichiers qui doivent être différents sur la machine de chaque développeur. Vous n’avez pas non plus besoin de vérifier les sous-produits de votre code. Je pense surtout aux dossiers de construction, aux fichiers objects, etc.

Eric Sink, qui est apparu sur le podcast n ° 36 de SO en janvier 2009, a écrit une excellente série d’articles sous le titre Source Control How-to .

(Eric est le fondateur de SourceGear qui commercialise une version compatible avec les plug-ins de SourceSafe, mais sans horreur.)

Juste pour append un autre ensemble de réponses:

  • Je m’engage chaque fois que je termine un travail. Parfois, c’est un petit bug qui a changé une ligne et m’a pris 2 minutes pour le faire; d’autres fois c’est deux semaines de sueur. De plus, en règle générale, vous ne commettez rien qui casse la construction. Ainsi, s’il vous a fallu beaucoup de temps pour faire quelque chose, prenez la dernière version avant de valider, et voyez si vos modifications rompent la génération. Bien sûr, si je rest longtemps sans commettre, cela me met mal à l’aise parce que je ne veux pas perdre ce travail. Dans TFS, j’utilise cette belle chose comme “étagères” pour cela. En SVN, vous devrez travailler autrement. Peut-être créer votre propre twig ou sauvegarder ces fichiers manuellement sur une autre machine.
  • Les twigs sont des copies de l’ensemble de votre projet. La meilleure illustration de leur utilisation est peut-être la gestion des versions des produits. Imaginez que vous travaillez sur un gros projet (par exemple, le kernel Linux). Après des mois de transpiration, vous êtes enfin parvenu à la version 1.0 que vous publiez au public. Après cela, vous commencez à travailler sur la version 2.0 de votre produit, ce qui sera bien meilleur. Mais entre-temps, il y a beaucoup de gens qui utilisent la version 1.0. Et ces personnes trouvent des bugs à corriger. Maintenant, vous ne pouvez pas corriger le bogue dans la version 2.0 à venir et l’expédier aux clients – ce n’est pas du tout prêt. Au lieu de cela, vous devez extraire une ancienne copie de la source 1.0, corriger le bogue et l’envoyer aux utilisateurs. C’est à quoi servent les twigs. Lorsque vous avez publié la version 1.0, vous avez créé une twig dans SVN qui a créé une copie du code source à ce stade. Cette twig a été nommée “1.0”. Vous avez ensuite continué à travailler sur la prochaine version de votre copie source principale, mais la copie 1.0 est restée telle quelle au moment de la publication. Et vous pouvez continuer à réparer les bugs. Les balises ne sont que des noms attachés à des révisions spécifiques pour faciliter leur utilisation. Vous pourriez dire “Révision 2342 du code source”, mais il est plus facile de l’appeler “Première révision stable”. 🙂
  • Je mets généralement tout dans le contrôle de source directement lié à la programmation. Par exemple, depuis que je crée des pages Web, je mets aussi des images et des fichiers CSS sous le contrôle des sources, sans parler des fichiers de configuration, etc. La documentation du projet n’y figure pas, mais c’est en fait une question de préférence.

D’autres ont déclaré que cela dépend de votre style.

La grande question pour vous est de savoir à quelle fréquence vous “intégrez” votre logiciel. Développement piloté par les tests, Agile et Scrum (et beaucoup d’autres) reposent sur de petits changements et une continuous integration. Ils prêchent que de petits changements sont faits, tout le monde trouve les pauses et les répare tout le temps.

Cependant, dans le cas d’un projet plus vaste (pensez au gouvernement, à la défense, à 100 k + LOC), vous ne pouvez tout simplement pas utiliser l’continuous integration car ce n’est pas possible. Dans ces situations, il est peut-être préférable d’utiliser les twigments pour effectuer beaucoup de petites tâches, mais ramener dans le coffre UNIQUEMENT ce qui fonctionnera et sera prêt à être intégré à la construction.

Toutefois, si les twigs ne sont pas correctement gérées, il peut être cauchemardesque d’avoir du travail dans le coffre, car tout le monde se développe à partir de différents endroits du tronc (ce qui est d’ailleurs l’un des arguments les plus importants pour Intégration continue).

Il n’y a pas de réponse définitive à cette question, le meilleur moyen est de travailler avec votre équipe pour trouver la meilleure solution de compromis.

Version Control avec Subversion est le guide pour les débutants comme pour les personnes âgées.

Je ne pense pas que vous pouvez utiliser Subversion efficacement sans lire au moins les premiers chapitres de ceci.

Pour commettre, j’utilise les stratégies suivantes:

  • engagez-vous aussi souvent que possible.

  • Chaque modification de fonctionnalité / correction de bogue devrait avoir son propre commit (ne pas valider plusieurs fichiers à la fois car cela rendrait l’historique de ce fichier peu clair – par exemple, si je modifie un module de journalisation et un module GUI indépendamment les deux modifications seront visibles dans les deux historiques de fichiers, ce qui rend difficile la lecture d’un historique de fichier),

  • ne rompez pas le build sur un commit – il devrait être possible de récupérer n’importe quelle version du repository et de le construire.

Tous les fichiers nécessaires à la création et à l’exécution de l’application doivent se trouver dans SVN. Les fichiers de test et autres ne devraient pas, sauf s’ils font partie des tests unitaires.

Beaucoup de bons commentaires ici, mais quelque chose qui n’a pas été mentionné sont les messages de validation. Celles-ci devraient être obligatoires et significatives. Surtout avec twigment / fusion. Cela vous permettra de garder une trace des modifications qui concernent les fonctionnalités des bogues.

par exemple svn commit . -m 'bug #201 fixed y2k bug in code' commit . -m 'bug #201 fixed y2k bug in code' indiquera à qui regarde l’historique ce à quoi cette révision était destinée.

Certains systèmes de suivi de bogues (par exemple, Trac) peuvent rechercher ces messages dans le référentiel et les associer aux tickets. Ce qui permet de déterminer facilement les modifications associées à chaque ticket.

La politique de notre travail se déroule comme ceci (équipe multi-développeurs travaillant sur un framework orienté object):

  • Mise à jour de SVN tous les jours pour connaître les changements de la veille

  • Engagez-vous tous les jours, donc si vous êtes malade ou absent le lendemain, quelqu’un d’autre peut facilement prendre la relève.

  • Ne commettez pas de code qui casse quoi que ce soit, car cela aura un impact sur les autres développeurs.

  • Travaillez sur de petits morceaux et engagez-vous quotidiennement AVEC DES COMMENTAIRES SIGNIFICATIFS!

  • En équipe: conservez une twig de développement, puis déplacez le code de pré-version (pour l’assurance qualité) dans une twig de production. Cette twig ne devrait avoir que du code pleinement opérationnel.

Le manuel TortoiseSVN TSVN est basé sur le livre de subversion , mais disponible dans beaucoup plus de langues.

Je pense qu’il y a deux manières de commettre la fréquence:

  1. S’engager très souvent, pour chaque méthode implémentée, petite partie du code, etc.
  2. Ne validez que des parties de code complétées, comme des modules, etc.

Je préfère le premier – parce que l’utilisation du système de contrôle de la source est très utile non seulement pour le projet ou la société, le premier est utile pour le développeur. Pour moi, la meilleure fonctionnalité consiste à restaurer tout le code tout en recherchant la meilleure implémentation de tâches affectée.