Mise à niveau vers SVN 1.5

Question

D'après ce que j'ai compris, svn 1.5 fournit un meilleur support pour les opérations de fusion. Donc, je considère la mise à niveau de svn 1.4. Le référentiel se trouve dans un fichier local (plus ou moins), et j'utilise svn depuis la ligne de commande.

À quels obstacles puis-je m'attendre et comment svn 1.5 gérera-t-il le référentiel existant sans les données de fusion?

modifier: En particulier, après avoir exécuté svnadmin upgrade , comment svn gérera-t-il les fusions des branches qui ont été fusionnées pour la dernière fois à l’ère 1.4?

Et svn-populate-node-origins-index a-t-il quelque chose à voir avec cela?

Référence: http://subversion.tigris.org/svn_1.5_releasenotes.html

Answer 1

La mise à niveau devrait être fluide, mais vous ne bénéficierez d'aucun avantage magique en matière de fusion tant que les informations de fusion ne sont pas renseignées - ce qui ne se produit pas avant que vous ne commenciez à l'utiliser.

Le seul avantage tangible des informations de fusion que j'ai trouvées est de pouvoir afficher une liste des fusions potentielles entre deux branches et de savoir les révisions déjà fusionnées. Cela n'affecte pas directement le nombre de conflits générés, comme le nombre de conflits générés, mais vous permet de rester sain d'esprit lorsque vous suivez ce qui se passe. Les fusions effectuées avant la mise à niveau ne causent pas de problèmes, elles apparaissent simplement à nouveau comme des fusions potentielles même si elles ont déjà été effectuées.

Cela dit, l'info de fusion est juste une propriété svn appelée svn: mergeinfo, de format:

/Project/name/trunk:1355-3985,4019,4026-4437,4478,4481

Il s'agit des informations de fusion réelles sur l'une de nos branches de publication de projet et nous indique exactement quelles révisions à partir du tronc sont sur le point d'être publiées. Cela signifie que, là où vous en avez besoin et où vous pouvez le résoudre, vous pouvez renseigner manuellement les informations de fusion et en tirer tous les avantages - c'est ce que nous avons fait pour les premières révisions, ci-dessus.

Cela vaut également la peine de regarder reshard.py , en particulier si le référentiel est grand et sur les fenêtres. Le format de référentiel 1.4 fsfs place toutes les révisions dans des fichiers distincts dans le même dossier. Windows commence l’exploration après quelques milliers de révisions. 1.5 Partage les révisions de groupes dans des dossiers séparés de 1000 chacun. 1.6 nous permettra de combiner les anciennes révisions dans un seul fichier de révision volumineux.

Answer 2

La mise à niveau est simple. Subversion est rétro-compatible à bien des égards. Cependant, vous devez mettre à niveau votre référentiel à l'aide de svnadmin upgrade .

Pour autant que je sache, le suivi des fusions ne fonctionnera que pour les fusions postérieures à la mise à niveau. Il n'y a pas de véritable moyen de reconstruire les informations manquantes.

De même, svn-populate-node-origins-index doit être exécuté sur ce référentiel, mais pour la raison indiquée dans le fichier lié (voir utilisation_summary).

Answer 3

En fonction de votre environnement de développement, vous aurez peut-être besoin de liaisons mises à jour. Netbeans 6.2, par exemple, ne fonctionne pas avec SVN 1.5.

Answer 4

Il existe de nombreux outils pour convertir un référentiel de subversion / cvs en un type complètement différent. En essayant de ne pas argumenter, je vous suggère de regarder toutes les autres options et de décider vous-même si l'une d'entre elles peut vous rendre la vie plus facile, comme les systèmes de contrôle de version distribués, par exemple. Git est celui qui prétend être meilleur.