svn: remplace le tronc par une branche

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

Il y a eu une réécriture majeure pour tout le système: les choses ont été déplacées, réécrites, remplacées, supprimées, renommées, etc. Le code réécrit a été testé et est prêt à remplacer l'ancien coffre.

Fondamentalement, l'ancienne ligne principale (Trunk 5) est étiquetée et se terminera ici. La branche réécrite (Branche 6) va devenir la nouvelle ligne principale (Trunk 7):

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

Tous les changements en cours de l'ancien 'Trunk' sont déjà incorporés dans la 'Rewritten branch'

Comment puis-je faire ceci?

Utilisez svn move pour déplacer le contenu de l'ancien coffre ailleurs et renommez la branche en trunk par la suite.

Notez que copier et déplacer dans svn fonctionnent comme des opérations de fichiers. Vous pouvez les utiliser pour déplacer / copier des éléments dans votre référentiel et ces modifications sont également versionnées. Pensez à "déplacer" comme à "copier + supprimer".

[EDIT] Nilbus vient de m'informer que vous obtiendrez des conflits de fusion lorsque vous l'utiliserez svn move.

Je pense toujours que c'est la bonne approche. Cela entraînera des conflits, mais si vous fusionnez soigneusement, il y a de fortes chances que vous ne perdiez aucune donnée. Si cela vous dérange, utilisez un meilleur VCS comme Mercurial ou Git .

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

Je sais que d'autres ici pensent que c'est inhabituel, mais j'aime le faire de cette façon. Lorsque j'ai une branche de fonctionnalité et que je suis prêt à la fusionner avec un tronc qui a également été considérablement modifié, je la fusionner avec une nouvelle branche, généralement nommée <FeatureBranchName>-Merged. Ensuite, je résous les conflits et teste le code fusionné. Une fois que c'est terminé, je déplace le coffre dans le dossier des balises pour ne rien perdre. Enfin, je déplace mon <FeatureBranchName>-Mergedvers le coffre.

De plus je préfère éviter la copie de travail lors des déplacements, voici des exemples des 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 1.5

Je regardais juste ce problème récemment, et la solution avec laquelle j'étais très satisfait était la performance

svn merge --ignore-ascendance tronc-url branch-url

sur la copie de travail de ma malle.

Cela n'essaie pas d'appliquer les changements de manière historique (maintenir les changements dans le coffre). Il "applique simplement le diff" entre le tronc et la branche. Cela ne créera aucun conflit pour vos utilisateurs dans les fichiers qui n'ont pas été modifiés. Vous perdrez cependant vos informations historiques de la branche, mais cela se produit quand même lorsque vous effectuez une fusion.

Vous recommandons de faire ces changements via l'outil de navigation du référentiel.

Tenter de grandes opérations de suppression et de déplacement via la copie de travail est un excellent moyen de tuer la copie de travail. Si vous êtes obligé d'utiliser la copie de travail, effectuez des validations incrémentielles après chaque opération de suppression ou de déplacement et METTEZ à JOUR votre copie de travail après chaque validation.

Si vous voulez faire de la branche le nouveau tronc (c.-à-d.) Supprimer tous les changements dans le tronc qui ont été faits depuis la création de la branche, vous pouvez 1. Créer une branche du tronc (à des fins de sauvegarde) 2. "annuler les modifications "sur le tronc (sélectionnez toutes les révisions après la création de la branche 3. Fusionner la branche avec le tronc.

L'histoire devrait rester ainsi.

Cordialement, Roger

Les solutions @Aaron Digulla et @kementeus sont réalisables. Pour les référentiels Subversion 1.4, les opérations de copie / déplacement peuvent rendre la migration future vers une structure de référentiel différente ou la division des référentiels difficile.

Je pense que les améliorations de la version 1.5 incluent une meilleure résolution de l'historique des mouvements / copies, donc ce ne serait probablement pas un problème pour un référentiel 1.5.

Pour un référentiel 1.4, je recommanderais d'utiliser svnadmin dumpet svndumpfilterd'effectuer le mouvement du tronc existant ailleurs, puis de déplacer la branche vers le tronc avec le même mécanisme. Chargez les deux fichiers de vidage dans un référentiel de test, vérifiez, puis déplacez-le en production.

Bien sûr, sauvegardez votre référentiel existant avant de commencer.

Cela préserve l'historique sans enregistrer explicitement le déplacement / la copie et facilite la réorganisation future, en préservant l'historique.

Edit: Comme demandé, la documentation du comportement 1.4, du livre 1.4 Red-Bean, Filtering Repository History

En outre, les chemins copiés peuvent vous poser des problèmes. Subversion prend en charge les opérations de copie dans le référentiel, où un nouveau chemin est créé en copiant un chemin déjà existant. Il est possible qu'à un moment donné de la vie de votre référentiel, vous ayez copié un fichier ou un répertoire à partir d'un emplacement svndumpfilterexclu vers un emplacement qu'il inclut. Afin de rendre les données de vidage autonomes,svndumpfilterdoit toujours afficher l'ajout du nouveau chemin, y compris le contenu de tous les fichiers créés par la copie, et ne pas représenter cet ajout comme une copie d'une source qui n'existera pas dans votre flux de données de vidage filtré. Mais comme le format de vidage du référentiel Subversion ne montre que ce qui a été modifié dans chaque révision, le contenu de la source de la copie peut ne pas être facilement disponible. Si vous pensez avoir des copies de ce type dans votre référentiel, vous voudrez peut-être repenser votre ensemble de chemins inclus / exclus, y compris peut-être également les chemins qui ont servi de sources de vos opérations de copie gênantes.

Cela s'applique aux migrations / réorganisations utilisant svndumpfilter. Il y a des moments où un peu de travail supplémentaire maintenant peut économiser beaucoup de travail supplémentaire plus tard, et en gardant une utilisation facile de svndumpfilterdisponible pour les migrations / réorganisations futures, atténue le risque à un coût relativement faible.

Bien que les réponses ci-dessus fonctionnent, ce ne sont pas les meilleures pratiques. Le dernier serveur svn et la piste client fusionnent pour vous. Ainsi svn sait quelles révisions vous avez fusionnées dans une branche et d'où. Cela aide beaucoup lors de la mise à jour d'une branche, puis de sa fusion dans le coffre.

Quelle que soit la version de Subversion que vous utilisez, il existe une méthode de bonnes pratiques pour récupérer les modifications d'une branche dans le tronc. Il est décrit dans le manuel Subversion: Contrôle de version avec Subversion, Chapitre 4. Branchement et fusion, maintien d'une branche synchronisée .

C'est une configuration vraiment bizarre / inhabituelle dans SVN, même si je pense que c'est loin d'être une "bonne pratique" du tout, de toute façon, je suppose que vous pourriez faire quelque chose comme:

• Checkout all the sourcetree (svn co therootsourcetree)
• Retirer le coffre (coffre svn rm)
• Copiez la branche dans le tronc (svn cp branches / thebranch / trunk)
• Supprimer la branche (svn rm branches / thebranch)
• Validez les changements

Bonne chance