svn : remplacez le tronc par branche

Question

Quelle est la meilleure façon de faire de l'une des branches d'un dépôt subversion, le nouveau coffre?

Il y a eu une réécriture majeure pour l'ensemble du système: les choses ont été déplacés, réécrit, remplace, supprimé, renommé, etc. Le nouveau code a été testé et est prêt à remplacer le vieux tronc.

Fondamentalement, la vieille canalisation principale (Trunk 5) est balisé et se terminera ici. La version remaniée de la branche (Branche 6) de devenir la nouvelle canalisation principale (route 7):

Tronc(1) --> Tronc(2) --> Tronc(5) --> × +--> nouveau Tronc(7)
 \ \ |
 fourche de fusion ???
 \ \ |
 +--> Branche(3) --> Branche(4) --> Branche(6) --+

Tous les changements en cours de l'ancien "Tronc" sont déjà intégrés dans le "Réécrit branche"

Comment puis-je faire cela?

Answer 1

Utilisation de svn move pour déplacer le contenu de l'ancien tronc d'ailleurs et renommer la branche au tronc par la suite.

Notez que de copier et de déplacer dans le svn de travail comme les opérations de fichiers. Vous pouvez les utiliser pour déplacer/copier des trucs autour de votre référentiel et ces changements sont versionnées, trop. Pensez à "déplacer" en tant que "copie+suppr".

[EDIT] nilbus juste me notifia que vous obtiendrez les conflits de fusion lorsque vous utilisez svn move.

Je pense toujours que ce est la bonne approche. Il va provoquer des conflits, mais si vous fusionnez avec soin, les chances sont que vous ne serez pas perdre toutes les données. Si cela vous ennuie, utiliser un meilleur VCS comme Mercurial ou Git.

Answer 2

Je suis d'accord avec l'aide de la commande svn move pour atteindre cet objectif.

Je sais que d'autres ici, pense que son inhabituel, mais je tiens à le faire de cette façon. Quand je la branche, et je suis prêt à fusionner avec un tronc qui a également modifié de façon significative, je vais fusionner à une nouvelle branche, généralement nommé <FeatureBranchName>-Fusionné. Puis-je résoudre les conflits et de tester le code fusionnées. Une fois terminée, je déplacez le tronc pour les étiquettes de dossier, donc je ne lâche rien. Et enfin j'ai déplacer mon <FeatureBranchName>-sur le trunk.

En plus je préfère éviter la copie de travail lors de la se déplace, voici quelques exemples de commandes:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Remarque: j'utilise la 1.5

Answer 3

Vous recommande de que faire ces changements par l’intermédiaire de l’outil de navigateur de référentiel.

Tente grand Suppr + déplacer des opérations par l’intermédiaire de la copie de travail est une excellente façon de tuer la copie de travail. Si vous êtes obligé d’utiliser la copie de travail, effectuer des validations supplémentaires après chacun supprimer ou déplacer des opération et mettre à jour votre copie de travail après chaque commit.

Answer 4

@Aaron Digulla et @kementeus solutions sont viables. Pour Subversion 1.4 référentiels, de copier/déplacer des opérations peuvent faire l'avenir de la migration vers une autre structure de référentiel ou de la séparation des dépôts difficile.

Je crois 1.5 améliorations apportées comprennent une meilleure résolution de déplacer/copier l'histoire, de sorte qu'il ne serait probablement pas un problème pour un 1,5 référentiel.

Pour un 1.4 référentiel, je vous recommande d'utiliser svnadmin dump et svndumpfilter pour effectuer le mouvement de l'existant tronc d'ailleurs, puis en déplaçant la branche vers le tronc avec le même mécanisme. Charger les deux dumpfiles dans un dépôt de test, vérifier, puis passer à la production.

Bien sûr, la sauvegarde de votre dépôt avant de commencer.

Cela préserve l'histoire sans enregistrement de la déplacer/copier explicitement et rend une future ré-organisation, la préservation de l'histoire, plus facile.

---

Edit: Comme l'a demandé, la documentation de l'1.4 comportement, à partir de la 1.4 Haricots Rouges livre, Filtrage de l'Historique du Dépôt

Aussi, copié chemins peuvent vous donner quelques de la difficulté. Subversion supporte la copie les opérations dans le référentiel, où un nouveau chemin est créé par la copie de certains déjà tracé existant. Il est possible qu'à un certain moment dans la vie de votre dépôt, vous pourriez avoir copié un fichier ou un répertoire à partir d'un emplacement qu' svndumpfilter est à l'exclusion, à une emplacement qu'il est compris. Dans afin de rendre les données de vidage auto-suffisante, svndumpfilterdes besoins pour toujours afficher l'ajout de la nouvelle chemin-y compris le contenu de tout les fichiers créés par la copie et de ne pas que représentent, plus que d'une copie de une source qui ne existent pas dans votre filtré vidage du flux de données. Mais parce que le dépôt Subversion de vidage format ne montre que ce qui a changé dans chaque révision, le contenu de la copie source pourrait ne pas être facilement disponibles. Si vous pensez que vous avez tout des copies de ce genre dans votre référentiel, vous voudrez peut-être repenser votre de inclus/exclus des chemins, peut-être, y compris les chemins d'accès que servi en tant que sources de votre gênants les opérations de copie, trop.

Cela s'applique aux migrations/réorganisations à l'aide de svndumpfilter. Il ya des moments où un peu de travail supplémentaire peut vous faire gagner beaucoup de travail supplémentaire plus tard, et en gardant une facilité d'utilisation de l' svndumpfilter disponible pour les futures migrations/réorganisations, réduit le risque à un coût relativement faible.