Comment utiliser SVN, Branch? Marque? Tronc?

Je cherchais un peu sur Google et je ne pouvais pas trouver un bon guide "débutant" sur SVN , pas plutôt dans le sens de "comment utiliser les commandes"; Comment contrôler mon code source?

Ce que je voudrais clarifier, ce sont les sujets suivants:

• À quelle fréquence vous engagez-vous? Aussi souvent que l'on appuierait sur Ctrl+ s?
• Qu'est-ce qu'une branche et qu'est-ce qu'une étiquette et comment les contrôlez-vous?
• Qu'est-ce qui entre dans le SVN? Seulement le code source ou partagez-vous d'autres fichiers ici aussi? (Ne sont pas considérés comme des fichiers versionnés.)

Je n'ai aucune idée de la branche et de la balise, donc je ne connais pas le but, mais je suppose que vous téléchargez des éléments dans le coffre et que lorsque vous faites une construction majeure, vous les déplacez vers la branche? 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 branchement et de balisage.

Voir également:

Continuez-vous le développement dans une branche ou dans le coffre

Stratégies de branchement

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 3 dernières années:

- s'engager aussi souvent que nécessaire; notre règle de base est de s'engager chaque fois que vous avez effectué un travail suffisant pour que ce serait un problème de devoir le refaire si les modifications étaient perdues; parfois je m'engage toutes les 15 minutes environ, d'autres fois cela peut prendre des jours (oui, parfois il me faut un jour pour écrire 1 ligne de code)

- nous utilisons des branches, comme l'une de vos réponses précédentes l'a suggéré, pour différents chemins de développement; pour le moment, pour l'un de nos programmes, nous avons 3 branches actives: 1 pour le développement principal, 1 pour l'effort encore inachevé de paralléliser le programme et 1 pour l'effort de le réviser pour utiliser les fichiers d'entrée et de sortie XML;

- nous n'utilisons que très peu de balises, même si nous pensons que nous devrions les utiliser pour identifier les versions en production;

Pensez au développement suivant une seule voie. À un moment ou à un stade du développement, le marketing décide de publier la première version du produit, de sorte que vous plantez un drapeau dans le chemin étiqueté «1» (ou «1.0» ou quoi que ce soit). À un autre moment, une étincelle brillante décide de paralléliser le programme, mais décide que cela prendra des semaines et que les gens veulent continuer sur la voie principale en attendant. Donc, vous construisez une fourche sur le chemin et différentes personnes se promènent sur les différentes fourches.

Les drapeaux sur la route sont appelés «balises», et les fourches de la route sont là où les «branches» se divisent. Parfois aussi, les branches se rejoignent.

- nous mettons tout le matériel nécessaire pour construire un exécutable (ou 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 quand nous avons des icônes et des fichiers de configuration et tout ce que vous voulez, cela va dans le référentiel. Certains documents se retrouvent dans le repo; certainement toute documentation telle que les fichiers d'aide qui pourraient faire partie intégrante du programme le fait, et c'est un endroit utile pour mettre la documentation du développeur.

Nous y installons même des exécutables Windows pour nos versions de production, afin de fournir un emplacement unique aux personnes à la recherche de logiciels - nos versions Linux sont envoyées sur un serveur et n'ont donc pas besoin d'être stockées.

- nous n'avons pas besoin que le référentiel soit à tout moment capable de fournir une dernière version qui se construit et s'exécute; certains projets fonctionnent de cette façon, d'autres non; la décision appartient au chef de projet et dépend de nombreux facteurs, mais je pense qu'elle échoue lors de modifications majeures d'un programme.

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

Aussi souvent que possible. Le code n'existe que s'il est sous contrôle de code source :)

Des commits fréquents (par la suite des ensembles de modifications plus petits) 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 devriez vous engager lorsque vous avez un morceau de code fonctionnel, mais je trouve utile de vous engager un peu plus souvent. Quelques fois, j'ai remarqué que j'utilisais le contrôle de source comme mécanisme d'annulation / rétablissement rapide.

Quand je travaille sur ma propre branche, je préfère m'engager 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?

Lisez le livre SVN - c'est un endroit où vous devriez commencer lorsque vous apprenez SVN:

• Qu'est-ce qu'une succursale?
• Mots clés

* What goes into the SVN?

La documentation, les petits binaires requis pour la construction et d'autres éléments qui ont une certaine valeur vont au contrôle de code source.

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 de code source et d'autres directives générales:

• Meilleures pratiques de contrôle de version (mon propre blog)
• Enregistrez-vous tôt, enregistrez-vous souvent (Coding Horror) (les commentaires ici contiennent beaucoup de bons conseils)
• Politique de validation de KDE

Ces questions Stack Overflow contiennent également des informations utiles qui peuvent être intéressantes:

• Organisation de la base de code source lors du mélange de deux ou plusieurs langages (comme Java et C ++)
• Suggestions pour un bon message de commit: format / ligne directrice?
• À quelle fréquence appliquer les modifications au contrôle de code source?
• Apprendre le contrôle de version et bien l'apprendre

En ce qui concerne les concepts de base de Subversion tels que le branchement 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 variables et parfois contradictoires. Je pense que la meilleure option pour vous est de lire ce que font les autres et de choisir les lignes directrices 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 justification qui la sous-tend. Donc, ne suivez aucun conseil à l'aveuglette, mais décidez plutôt de ce qui 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 le mieux 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 de quelle manière 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 s'engager si cela brise la construction (ou la fonctionnalité).

Les branches peuvent être utilisées de deux manières, généralement: 1) Une branche active pour le développement (et le tronc reste stable), ou 2) des branches pour des chemins de développement alternatifs.

Les balises sont généralement utilisées pour identifier les versions, afin qu'elles ne se perdent pas dans le mix. La définition de «libération» dépend de 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 branches, mais nous obtenons ensuite des idées sans rapport avec les balises / versions ou quelque chose qui affecte.

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

On obtient le tronc -> forme des branches -> produit des fruits (tags / rejets).

L'idée étant que vous développez le projet à partir d'un tronc, qui crée ensuite des branches une fois que le tronc est suffisamment stable pour contenir la branche. Ensuite, lorsque la branche a produit un fruit, vous le cueillez de la branche et le libérez comme étiquette.

Les balises sont essentiellement des livrables. Alors que le tronc et les branches les produisent.

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

À quelle fréquence vous engagez-vous? Aussi souvent que l'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 que vous engagez lorsque vous remplissez un morceau de code fonctionnel, même petit.

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

Premièrement, le coffre est l'endroit où vous faites votre développement actif. C'est la ligne principale de votre code. Une branche est un écart par rapport à la ligne principale. Cela peut être une déviation majeure, comme une version précédente, ou simplement une modification mineure que vous souhaitez essayer. Une balise est un instantané de votre code. C'est un moyen d'attacher une étiquette ou un signet à une révision particulière.

Il convient également de mentionner que dans la subversion, le tronc, les branches et les balises ne sont que convention. Rien ne vous empêche de travailler dans des balises ou d'avoir des branches qui sont votre ligne principale, ou de ne pas tenir compte du schéma tag-branch-trunk tous ensemble. Mais, à moins d'avoir une très bonne raison, il vaut mieux s'en tenir aux conventions.

Qu'est-ce qui entre dans le SVN? Seulement le code source ou partagez-vous d'autres fichiers ici aussi?

Également un choix personnel ou d'équipe. Je préfère garder tout ce qui concerne la construction dans mon référentiel. Cela inclut les fichiers de configuration, les scripts de construction, 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 d'enregistrer les sous-produits de votre code. Je pense principalement aux dossiers de construction, aux fichiers objets, etc.

Eric Sink, qui est apparu sur le podcast SO n ° 36 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 plug-compatible de SourceSafe, mais sans horrible.)

Juste pour ajouter un autre ensemble de réponses:

• Je m'engage chaque fois que je termine un travail. Parfois, c'est une petite correction de bogue qui a juste changé une ligne et m'a pris 2 minutes à 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 interrompent la construction. Bien sûr, si je reste longtemps sans m'engager, cela me met mal à l'aise car je ne veux pas perdre ce travail. Dans TFS, j'utilise cette belle chose comme "étagères" pour cela. Dans SVN, vous devrez travailler d'une autre manière. Créez peut-être votre propre branche ou sauvegardez ces fichiers manuellement sur une autre machine.
• Les branches 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 grand projet (par exemple, le noyau Linux). Après des mois de sueur, vous êtes enfin arrivé à la version 1.0 que vous publiez au public. Après cela, vous commencez à travailler sur la version 2.0 de votre produit qui sera bien meilleure. Mais entre-temps, il y a aussi beaucoup de gens qui utilisent la version 1.0. Et ces personnes trouvent des bogues que vous devez corriger. Maintenant, vous ne pouvez pas corriger le bogue dans la prochaine version 2.0 et l'envoyer 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 là-bas et l'envoyer aux gens. C'est à cela que servent les succursales. Lorsque vous avez sorti le 1. 0 version vous avez fait une branche dans SVN qui a fait une copie du code source à ce stade. Cette branche a été nommée "1.0". Vous avez ensuite continué à travailler sur la version suivante dans votre copie source principale, mais la copie 1.0 est restée là telle qu'elle était au moment de la publication. Et vous pouvez continuer à corriger les bogues là-bas. Les balises ne sont que des noms attachés à des révisions spécifiques pour en faciliter l'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 qui se rapporte directement à la programmation. Par exemple, depuis que je crée des pages Web, je mets également des images et des fichiers CSS dans le contrôle de code source, sans parler des fichiers de configuration, etc. La documentation du projet ne s'y trouve 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. Le développement piloté par les tests, Agile et Scrum (et bien d'autres) reposent sur de petits changements et une intégration continue. Ils prêchent que de petits changements sont faits, tout le monde trouve les pauses et les répare tout le temps.

Cependant, sur un projet plus important (pensez gouvernement, défense, 100k + LOC), vous ne pouvez tout simplement pas utiliser l'intégration continue car ce n'est pas possible. Dans ces situations, il peut être préférable d'utiliser le branchement pour faire beaucoup de petits commits, mais ramenez UNIQUEMENT dans le coffre ce qui fonctionnera et est prêt à être intégré dans la construction.

Une mise en garde avec les branchements est que s'ils ne sont pas gérés correctement, cela peut être un cauchemar dans votre référentiel de travailler dans le coffre, car tout le monde se développe à partir de différents endroits du coffre (ce qui est d'ailleurs l'un des plus grands arguments 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.

Le contrôle de version avec Subversion est le guide pour les débutants comme pour les anciens.

Je ne pense pas que vous puissiez utiliser Subversion efficacement sans lire au moins les premiers chapitres de celui-ci.

Pour m'engager, j'utilise les stratégies suivantes:

• engagez-vous aussi souvent que possible.

• Chaque changement de fonctionnalité / correction de bogue doit avoir son propre commit (ne pas valider plusieurs fichiers à la fois car cela rendra l'historique de ce fichier peu clair - par exemple, si je change un module de journalisation et un module d'interface graphique indépendamment et que je commets les deux à la fois, les deux modifications seront visibles dans les deux historiques de fichiers. Cela rend la lecture de l'historique de fichiers difficile),

• ne cassez pas la compilation sur aucun commit - il devrait être possible de récupérer n'importe quelle version du référentiel et de la construire.

Tous les fichiers nécessaires à la création et à l'exécution de l'application doivent être au format 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é est les messages de validation. Ceux-ci devraient être obligatoires et significatifs. Surtout avec le branchement / fusion. Cela vous permettra de garder une trace de quels changements sont pertinents pour quelles fonctionnalités de bogues.

par exemple svn commit . -m 'bug #201 fixed y2k bug in code' dira à quiconque regarde l'historique à quoi servait cette révision.

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 très facilement les changements associés à chaque ticket.

La politique de notre travail est la suivante (équipe de plusieurs développeurs travaillant sur un framework orienté objet):

• Mise à jour de SVN tous les jours pour obtenir les modifications de la veille

• Engagez-vous tous les jours afin que si vous êtes malade ou absent le (s) jour (s) suivant (s), quelqu'un d'autre peut facilement prendre le relais là où vous vous êtes arrêté.

• 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: gardez une branche de développement, puis déplacez le code de pré-version (pour QA) dans une branche de production. Cette branche ne devrait avoir que du code entièrement fonctionnel.

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 façons de commettre une fréquence:

1. Engagez très souvent, pour chaque méthode implémentée, une petite partie de code, etc.
2. Validez uniquement les parties de code terminées, comme les modules, etc.

Je préfère le premier - parce que l'utilisation du système de contrôle de source est très utile non seulement pour un projet ou une entreprise, le premier de tout c'est utile pour le développeur. Pour moi, la meilleure fonctionnalité est de restaurer tout le code tout en recherchant la meilleure implémentation de tâche attribuée.