Comment utiliser SVN, Branch? Marque? Tronc?

Question

J'ai été googler un peu et ne pouvait pas trouver un bon "débutants" guide de SVN, pas dans le sens de "comment puis-je utiliser les commandes" plutôt; Comment puis-je contrôler mon code source?

Ce que je voudrais effacer les est les sujets suivants:

• Combien de fois avez-vous engager? Comme souvent, comme on le ferait appuyez sur Ctrl + s?
• Ce qui est une Branche et qu'est ce qu'un Tag et comment les contrôler?
• Ce qui se passe dans le SVN? Le Code Source ou de vous faire partager d'autres fichiers, ici aussi? (Pas considérés comme des fichiers versionnés.. )

Je n'ai aucune idée de ce que la branche et de l'étiquette est donc je ne sais pas le but, mais mon sauvage suppose que vous vous charger des trucs dans le coffre, et quand tu fais un build majeure vous déplacer à la direction? Donc, ce qui est considéré comme l'un des principaux construire dans ce cas?

Answer 1

Je me suis posé les mêmes questions lorsque nous sommes arrivés à mettre en œuvre la Subversion ici -- environ 20 développeurs répartis sur les 4 - 6 projets. Je n'ai pas trouvé une bonne source avec "la réponse". Voici quelques pièces de la façon dont notre réponse a développé au cours des 3 dernières années:

-- s'engager aussi souvent que cela est utile; notre règle d'or est de s'engager à chaque fois que vous avez fait suffisamment de travail que ce serait un problème d'avoir à re-faire si les modifications se sont perdus; parfois j'ai commis toutes les 15 minutes, d'autres fois, il pourrait être jours (oui, parfois, il me prend une journée pour écrire 1 ligne de code)

-- nous utilisons des branches, comme l'une de vos précédentes réponses suggérées, pour les différentes voies de développement; à droite maintenant pour l'un de nos programmes, nous avons 3 branches actives: 1 pour le développement principal, 1 pour le pas encore inachevée de l'effort de paralléliser le programme, et 1 pour l'effort de les réviser afin d'utiliser le format XML d'entrée et de sortie des fichiers;

-- nous avons à peine d'utiliser des tags, si nous pensons que nous devrions les utiliser pour identifier les rejets dans la production;

Penser le développement instance par le même chemin. À un moment ou à un état de développement marketing décider de sortir la première version du produit, de sorte que vous plante un drapeau dans le chemin étiqueté '1' (ou '1.0' ou avez-vous). À un autre moment certains étincelle brillante décide de paralléliser le programme, mais décide que cela va prendre des semaines, et que les gens veulent garder en descendant le chemin principal dans l'intervalle. Afin de vous construire un embranchement du chemin d'accès, et les différentes personnes errent dans les différents forks.

Les drapeaux de la route sont appelés "tags", et la fourche de la route sont où les "branches" diviser. Parfois, aussi, des branches de revenir ensemble.

-- nous avons mis tout le matériel nécessaire pour créer un fichier exécutable (ou système) dans le référentiel, C'est à dire au moins le code source et faire fichier (ou les fichiers de projet pour Visual Studio). Mais quand nous avons des icônes et des fichiers de configuration et toutes les autres choses, qui va dans le référentiel. Une partie de la documentation trouve son chemin dans les opérations de pension; certainement toute la documentation comme les fichiers d'aide qui pourrait être partie intégrante du programme, et c'est un lieu utile pour mettre de la documentation du développeur.

Nous avons même mis les exécutables Windows pour notre production de communiqués de là, à fournir un emplacement unique pour les personnes à la recherche pour logiciel -- nos distributions Linux sur un serveur, donc n'a pas besoin d'être stockées.

-- nous ne nécessitent pas le dépôt à tout moment être capable de délivrer une dernière version qui génère et exécute; certains projets fonctionnent de cette façon, n'est pas le cas; la décision revient au chef de projet et dépend de nombreux facteurs, mais je pense qu'il se décompose lors de la prise de changements majeurs à un programme.

Answer 2

Le livre de la subversion est une excellente source d’informations sur les stratégies pour la pose de votre référentiel, ramification et le marquage.

Voir aussi :

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

Ramification des stratégies

Answer 3

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

Aussi souvent que possible. Le Code n'existe pas, sauf si elle est sous contrôle de code source :)

Fréquentes s'engage (par la suite, les petits ensembles de modifications) permet d'intégrer vos modifications facilement et augmenter les chances de ne pas casser quelque chose.

D'autres personnes ont fait remarquer que vous devez commettre lorsque vous avez une fonctionnelle morceau de code, mais je trouve qu'il est utile de s'engager un peu plus souvent. Quelques temps j'ai remarqué que j'utilise le contrôle de code source comme un rapide mécanisme d'annuler/refaire.

Quand je travaille sur mon propre branche, je préfère y consacrer autant que possible (littéralement aussi souvent que je presse ctrl+s).

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

Lire SVN livre - c'est un endroit que vous devriez commencer lorsque l'apprentissage SVN:

• Ce qui est une Branche?
• Tags

* What goes into the SVN?

La Documentation, les petits exécutables nécessaires pour la construction et d'autres choses qui ont une certaine valeur, aller à la source de contrôle.

Answer 4

Voici quelques ressources lors de la validation de la fréquence, des messages de commit, la structure du projet, ce qu'il faut mettre sous contrôle de code source et d'autres lignes directrices:

• Les meilleures Pratiques de Contrôle de Version (de mon propre blog)
• Check-in plus Tôt, Vérifiez Souvent (Code de l'Horreur) (commentaires ici contiennent beaucoup de bons conseils)
• KDE commettre politique

Ces Débordement de Pile questions contiennent également des informations utiles qui peuvent être d'intérêt:

• L'organisation de la base de code source lors du mélange de deux ou plusieurs langues (comme Java et C++)
• Des Suggestions pour un bon message de commit: format/orientation?
• Comment souvent pour valider les modifications apportées à la source de contrôle?
• L'apprentissage de Contrôle de Version, et de l'apprentissage de la bonne

Concernant la base de Subversion des concepts tels que la ramification et le marquage, je pense que c'est très bien expliqué dans le livre de Subversion.

Que vous pouvez réaliser, après avoir lu un peu plus sur le sujet, l'opinion des gens sur ce que les meilleures pratiques dans ce domaine sont souvent différentes et parfois contradictoires. Je pense que la meilleure option pour vous est de lire à propos de ce que les autres font et de choisir les lignes directrices et les pratiques que vous vous sentez de faire le plus de sens pour vous.

Je ne pense pas que c'est une bonne idée d'adopter une pratique si vous ne comprenez pas le but de celui-ci ou n'est pas d'accord avec le raisonnement derrière elle. Donc, ne pas suivre tous les conseils à l'aveuglette, mais plutôt de vous faire votre propre idée sur ce que vous pensez qui fonctionnera le mieux pour vous. Aussi, à expérimenter avec différentes façons de faire les choses est une bonne façon d'apprendre et de savoir comment vous le meilleur comme pour le travail. Un bon exemple de cela 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 laquelle vous préférez jusqu'à ce que vous avez essayé réellement dans la pratique.

Answer 5

Commettre fréquence dépend de votre style de gestion de projet. Beaucoup de gens s’abstenir de commettre si elle te casse le build (ou fonctionnalités).

Branches peuvent être utilisés de deux façons différentes, en général : 1) une branche active pour le développement (et le tronc reste stable), ou 2) branches pour les chemins d’autre dev.

Tags sont généralement utilisés pour identifier les versions, donc ils ne se perdent dans le mélange. La définition de « émission » vous appartient.