Gestion des versions SVN

Question

Quand je regarde dans le svn log Je souhaite vraiment que je pouvais voir des marqueurs qui me disent quand les rejets ont été faites. Je l'ai vu dans d'autres systèmes de contrôle de version, tels que PVCS et Perforce .

Peut-on faire dans SVN? Je l'ai fait un peu de recherche et jusqu'à présent, il semble que ce genre de chose n'est pas pris en charge.

Modifier

Nous ne voulons pas avoir à copier notre source dans un dossier différent pour chaque version. Il en résulte une énorme quantité de duplication inutile des fichiers sur la machine développeurs et ne nous donne un enregistrement du numéro de révision de chaque version. Je peux le faire en utilisant un document de texte!

Edit2

Mon but est d'avoir une vue unique qui me montre une chronologie de mes communiqués, entre lesquels je peux voir tous les changements de code qui ont eu lieu entre chaque version. Cela permet alors plus facile de compiler les notes de version.

Answer 1

Richard, les balises sont très proches, mais je me demande si ce que vous avez besoin peut-être pas une branche de sortie dédié.

Pour cela, faire une branche du tronc tôt appelé quelque chose comme « libération ». Ensuite, travailler sur le tronc comme normal, lorsque vous êtes prêt pour une sortie, fusionner vos modifications du tronc dans « Release ». Ceci est la seule façon que vous devez modifier la libération.

Vous pouvez ensuite marquer de sortie si vous voulez, pas 100% nécessaire.

Mais qu'est-ce que cela vous donnera est une branche qui a un sous-ensemble des révisions du tronc en elle. Découvrez vos dates de sortie avec:

svn log --stop-on-copy svn://server/project/branches/release

Cela vous donnera une liste des dates de sortie (avec les révisions). Pour voir ce qui est dans chaque version faire:

svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>

Notez également qu'en travaillant de cette façon, vous n'êtes pas limité à strictement libération séquentielle de tout dans le coffre - vous pouvez choisir des révisions cerises, à l'exclusion des révisions si vous ne voulez pas les libérer pour l'instant, mais y compris après révisions.

Answer 2

Pas en tant que tel. La façon de faire accepter les rejets dans SVN est d'avoir un répertoire « tags » où est copié votre source de publication de chaque version particulière. Par exemple /tags/release-0.11 ... Il n'y a rien qui vous empêche de jouer avec le répertoire tags par hasard, hors de la boîte, mais certaines personnes aiment mettre en place des crochets pré-engager pour empêcher commits accidentelle de libérer les tags.

Voici un article décent décrivant un processus de libération dans SVN.

Answer 3

  

Mon but est d'avoir une vue unique   me montre une chronologie de mes communiqués,   entre lesquels je peux voir tous les   les changements de code qui ont eu lieu entre   chaque version.

Avez-vous étudié le graphique de révision SVN Tortoise? Si vous marquez chaque version (qui, comme d'autres l'ont souligné ne concerne pas la copie de fichiers, que ce soit sur le serveur ou le poste de travail), vous pouvez voir toutes les révisions dans l'ordre chronologique, avec les balises indiquant les rejets réels. Vous pouvez diff entre les versions et / ou le tronc par les deux révisions hilighting qui vous intéressent et sélectionner diff dans le menu contextuel.

Answer 4

Copie du tronc à un chemin de balises dans le référentiel svn est le moyen d'y parvenir. Il est une copie svn, donc ne se termine pas avec des doublons de fichiers sur le serveur de dépôt svn. Vous avez uniquement les fichiers en double sur place si vous avez choisi la commande d'un chemin de svn autre que le tronc. Commits sur ces copies de travail puis revenir en arrière sur le chemin de svn ils ont été contrôlés à partir.

Ceci est essentiellement une mise en oeuvre classique spécifique de ramification dans svn. Jetez un coup d'oeil au livre svn en ligne pour plus de détails.

Answer 5

Le marqueur serait le message de commit écrit lorsqu'une étiquette pour la libération est faite (une copie svn aux / tags). Atleast qui est la méthode la plus utilisée.

Answer 6

Bien que Subversion ne fournit pas la gestion des versions et de lui-même, les outils de contrôle de version ne sont généralement pas chargés de cette activité. Ce que vous recherchez est une activité / question / changement d'outil de gestion qui peut interagir avec Subversion.

À cette fin, nous utilisons JIRA sur mon lieu de travail et nous faisons le lien avec Subversion. JIRA fournit un historique de feuille de route et le changement qui inclut les questions dans chaque version. Chacun de ces problèmes a des liens avec les changements dans le contrôle de code source. Ainsi, vous pouvez lier les changements dans le code source avec les versions publiées.

Je pense qu'il est généralement préférable de garder ces deux outils distincts. Bien que Perforce en particulier tente de lier les deux ensemble, ils ne le font que tout simplement. Il y a certaines choses, comme emailing utilisateurs des modifications apportées aux questions, d'ajouter des commentaires aux questions, ajouter des pièces jointes à des questions qui sont beaucoup mieux fait dans une pièce spécialisée de logiciels comme Jira. D'autre part Jira est pas très bon à versioning, la source et la fusion de branchement ... qui est mieux gérée dans un morceau logiciel spécialisé comme Subversion.

Pour la divulgation complète, il existe d'autres outils que Jira comme Bugzilla, Trac, IBM Rational Jazz, etc. qui peuvent faire la même chose avec Subversion que Jira fait bien avec différents niveaux de fonctionnalité.

Answer 7

Jetez un oeil à tous les sujets du livre SVN:

Balises et Parcourir le référentiel

et branches sont « copie à l'écriture », ce qui signifie qu'il n'y a pas des copies supplémentaires dans le référentiel. En général, un développeur individuel aurait pas besoin d'avoir une copie locale à moins qu'il en avait besoin pour une raison (le développement sur une branche I.E.).

Si vous marquez chaque version, vous pouvez voir les balises en naviguant sur le référentiel. Les liens ci-dessus parlent directement sur les outils de ligne de commande, mais il y a également des outils GUI comme TortoiseSVN sur Windows. Vous pouvez obtenir l'histoire, faire des comparaisons, etc.

Pour voir les modifications apportées dans un communiqué, vous simplement montrer un journal du tronc de la révision de l'étiquette que vous voulez revenir à la révision de la balise précédente +1. Cela ressemble à un travail supplémentaire, mais il est assez simple une fois que vous y habituer.

Avec nos outils de construction, nous nous engageons également un fichier avec des informations de numéro de version dans le tronc et le commentaire a le numéro de version de la construction. Si votre code principal est dans le coffre, cela peut aussi fonctionner comme un marqueur pour ce qui est dans une construction (regardez entre la version engage).

Answer 8

1 pour l'utilisation du message de validation.

Pour un projet que je créé un utilisateur appelé SVN build. La machine de construction utilisé pour cette connexion SVN. Chaque fois que la machine de construction / processus a une construction à jour également un fichier et le message de commit SVN est la version / autre identifiant pour la construction.

Ensuite, nous avons également créé une balise pour cette construction. De cette façon, dans le coffre, nous pourrions voir le construit quand / où ils sont entrecoupés d'autres changements.

est de créer un autre fichier appelé build (ou tout ce que vous voulez) et ajouter à cela ou tout simplement modifier dans votre script / processus de construction, puis vérifiez-le dans / commettre ma suggestion (la plus simple façon de le faire) avec le nom de la version que le message de commit. Facile. Il sera alors affiché dans vos requêtes d'histoire.

Answer 9

En outre, si vous savez quelles révisions vous pouvez vous comparez faire une diff SVN et vous verrez quels fichiers ont changé et comment entre les deux révisions.

Je ne sais pas sur votre configuration totale mais quelqu'un TortoiseSVN mentionné. C'est définitivement un bon départ. Personnellement, j'utiliser Eclipse avec le plug-in Subclipse et il me permet de réaliser diffs dans un environnement graphique entre les versions. Tant que vous avez votre projet peut comparer votre toute révision à toute autre révision et en tant que tel vous n'avez pas besoin d'avoir toutes sortes de duplication de fichiers.

En outre, nous avons l'habitude mis en place trois répertoires dans chaque dépôt. Branches, le tronc et Balises. Comme quelqu'un a noté, les balises sont utilisées spécifiquement pour identifier un communiqué.

Answer 10

Je rencontre le même problème et la façon dont je l'ai essayé de le réparer pour mon entreprise est d'avoir un dossier « libération » dans le coffre, ce dossier ne contient que l'exécutable réel ou ce qui doit faire partie du déploiement.

Je crée un nouveau dossier pour chaque version commençant par « 1.0.0.0 » dans le dossier « libération » et marquer également le code dans le cas avec le nom du dossier même version i.e. 1.0.0.0.

Je ne sais pas si elle est la bonne façon de le faire, mais il résout mon problème pour savoir exécutable que j'ai déployé.

Answer 11

Si vous suivez la convention normale svn des « tags / branches / tronc » à la racine de votre dépôt, les développeurs ne veulent généralement vérifier l'ensemble du référentiel, seulement à partir du coffre vers le bas.

Answer 12

Je voudrais proposer une approche différente qui devrait aider à résoudre votre problème déclaré: créer des notes de publication et l'affichage des différences de code entre les versions.

Nous utilisons un utilitaire appelé SubWCRev qui vient avec tortoisesvn. Nous avons un événement post-build qui saisit le numéro de révision SVN et il colle dans un fichier - dans le cas des sites web, nous avons mis cela dans un fichier appelé version.html. Puis, à tout moment vous pouvez lier votre communiqué (que ce soit les releas actuellement QA, Prod, ou tout autre environnement) au nombre exact de révision SVN. Plus de marquage, pas plus se demander ce qui est inclus dans un communiqué, les développeurs pas plus mise sur écoute de mettre à jour un fichier de version.

Afin de déterminer ce qui est a été inclus dans un communiqué, vous pouvez simplement tirer vers le haut les journaux SVN de révision X à la révision Y et copiez les commentaires dans un document et modifier pour faire un joli notes de version doc. La même chose est vrai pour la révision du code ou diffing les versions; il suffit d'utiliser les numéros de révision liés à votre version.html, properties.cs, readme.txt, etc.

Je voudrais aussi vous suggérons d'avoir une sorte de dépôt d'artefact pour tenir votre builds. Si vous passez à l'aide du numéro de révision SVN que votre numéro de version, vous pouvez toujours revenir à cette révision exacte à SVN qui signifie que vous n'avez pas besoin des balises ou des copies de votre source pour chaque version autour de la pose dans SVN.

Answer 13

Pour votre information,

copie SVN n'est pas sur papier, il est juste relie donc ne prendre aucun espace autre que les fichiers modifiés. Et ces versions prendra de l'espace de toute façon. créant ainsi une copie pour chaque nouvelle version ne prendra pas l'espace.