Usages de Subversion [fermé]

Question

Je commence tout juste à utiliser "Subversion". avec le client Tortoise SVN " pour un de mes projets opensource hébergé sur "Google Code". J'aimerais avoir quelques bonnes pratiques d'utilisation. Je suis la structure de dossier par défaut (coffre, branche, étiquette). Voici les questions

1. Quand ferez-vous l'enregistrement initial? Est-ce seulement après avoir terminé un ensemble de fonctionnalités ou dès le premier jour de développement?
2. Dans quel répertoire l'archivage initial va? Est-ce dans " trunk " ou vous enregistrez dans " branche " et fusionner avec "tronc". une fois une fonctionnalité terminée. Dans ce cas, "tronc" sera vide jusqu'à ce que la fonctionnalité soit terminée.
3. Chaque fois que des modifications sont apportées, enregistrez-vous dans "Trunk". directement? Sinon, votre copie de travail utilisera toujours " branche " répertoire, non?

Toute aide serait appréciée.

Answer 1

1. Je vous recommande de vérifier vos fichiers avant de commencer à les modifier en profondeur ( se connecter tôt, se connecter souvent ).

2. Cela dépend. Certaines personnes aiment que le tronc stable fonctionne dans des branches, puis fusionnent les branches dans le tronc lorsque les fonctionnalités sont prêtes, mais vous pouvez également passer directement à le coffre.

3. Cela dépend également de votre façon de travailler et de ce que vous aimez avoir dans le coffre (la dernière version stable ou la dernière version à la pointe du progrès).

Answer 2

Je suggère de vérifier tôt et souvent.

Il existe de nombreuses façons de procéder, mais la plus courante avec laquelle j’ai travaillé avec succès est le travail en dehors d’une branche de développement et la fusion avec le tronc lorsque vous arrivez à un point stable (versions mineures, jalons, etc.).

Si ce n’est déjà fait, consultez le livre rouge , c’est une excellente ressource pour les informations svn.

Answer 3

Lors de la création d'un nouveau projet à partir de rien, je le fais généralement dans une zone utilisateur de SVN telle que

.

/svn/users/me/project1

c’est parce que la plupart des projets sont au départ des prototypes jetables et que j’utilise rarement des branches pour ceux-ci. Une fois qu'un projet devient officiel et approche de son premier "prototype" la version que je vais migrer vers son propre référentiel

/svn/project1/trunk

L'utilisation de branches nécessite un peu de travail supplémentaire, nous ne les utilisons donc que si elles sont nécessaires. C'est-à-dire que plusieurs personnes travaillent sur le même projet et que les collisions sont fréquentes ou que je travaille sur une fonctionnalité que je pourrais décider de revenir en arrière et de jeter. Si cela est fait dans une branche, je peux simplement choisir de ne pas fusionner et de simplement le supprimer.

Answer 4

Toutes les réponses suggèrent d’arriver tôt, d’arriver souvent, je suis tout à fait d’accord. Donc c'est tout ce que je vais dire à ce sujet. Cependant, je lis le résumé comme suit: Quel type d’utilisation peut être adapté à Subversion? Alors, voici une réponse pour cela.

J'ai lu des articles sur des entreprises utilisant Subversion comme référentiel d'applications. Ils indiquent donc au serveur qu'ils souhaitent installer la version X de l'application Y. Le serveur exécute ensuite une mise à jour sur le serveur SVN. Et ils y ont également stocké des fichiers de configuration. Et toutes les modifications apportées à la configuration (via une interface Web distincte pour les clients finaux) étaient ensuite validées dans le référentiel de configuration SVN. C'est génial. 'Bien sûr, ces gars-là utilisaient MS Power Shell sur Win2k3, mais la technique peut toujours être appliquée ailleurs.

Answer 5

Arrivez IMMÉDIATEMENT, pas tôt. Même si vous n'avez rien de plus à commettre qu'un fichier texte ad-hoc contenant des remue-méninges et du code psuedo horriblement crypté, validez-le.

Je (comme beaucoup) trouve des projets comme le vôtre tout en faisant une recherche de code ou en recherchant un programme qui fasse ce que je veux. Je vais lire votre page d'accueil, puis parcourir immédiatement votre coffre SVN pour voir ce que vous faites.

Si vous avez zéro code dans le coffre, je vais probablement oublier tout de vous. Si vous avez au moins un fichier expliquant votre conception et du code psuedo, je commencerai probablement à vous envoyer des correctifs qui illustrent mes idées.

Un projet avec un référentiel vide crie "des démangeaisons qui ne seront jamais éraflées". .. alors poussez quelque chose le plus tôt possible.

Après cela, engagez-vous souvent. J'aime faire de nombreux petits engagements ordonnés pour qu'il soit facile de suivre les régressions et d'annuler / corriger les révisions toxiques.

Answer 6

1. Enregistrez-vous une fois que vous avez créé votre structure de projet / solution de base vide . Vide car à cet état, il est en fait compilable bien qu'aucun code ne fonctionne. Le principe est de garder le projet entier - au moins - dans un état compilable tout au long du développement, au fur et à mesure que l'équipe engage de petites modifications régulières et régulières, afin que la construction ne soit pratiquement pas cassée.

2. Il n’existe pas de loi exigeant que l’enregistrement initial se produise au niveau du coffre ou d’une succursale. Vous pouvez démarrer le tronc avec un projet vide afin qu'il soit stable dès le début, puis vous lancer dans le développement et le fusionner avec le tronc une fois terminé. Vous pouvez également choisir d’enregistrer le projet vide dans une branche et de développer la première fonctionnalité opérationnelle ou de base avant de fusionner quelque chose de substantiel dans le tronc. Quoi qu’il en soit, sur la base du point 1, le tronc devrait être stable et de haute qualité . Ne fusionner que du contenu de haute qualité dans le coffre.

3. Encore une fois, il n’existe pas de mandat strict sur ce type de pratiques. Certaines équipes distribuent tout , même un simple refactoring des changements de noms de variables. Certaines équipes ne savent même pas créer des branches / fusionner et développent tout dans une seule branche (le tronc). Chaque équipe a son propre niveau d’équilibre sur cette question. Ma directive personnelle est de créer des branches pour tester si de nouvelles fonctionnalités, des corrections de bugs majeurs ou des modifications importantes sont nécessaires. S'il s'agit d'une correction mineure telle que des fautes d'orthographe ou l'affichage de quatre décimales au lieu de deux dans la page Web, la correction de la copie de la ligne réseau devrait suffire. Bien sûr, les interprétations de " majeur " par rapport à " mineur " vont différer de sorte que les chefs de développement / équipe doivent établir leurs normes. Dans les deux cas, des tests unitaires / d'intégration doivent accompagner les modifications afin de vérifier que la succursale ou la jonction fonctionnent comme prévu, sans faille autant que possible. Le mot clé à retenir est toujours "code de haute qualité et testé".