Mercurial de Subversion: se déplace, renomme et balises

Question

je une prise en pension de subversion avec la mise en page suivante:

svnrepo/projectA/trunk 
svnrepo/projectA/tags 
svnrepo/projectA/branches 
svnrepo/projectB/trunk 
svnrepo/projectB/tags 
svnrepo/projectB/branches 

que je voudrais passer à une prise en pension Mercurial avec une mise en page révisée:
hgrepo/projectA
hgrepo/projectB

Quelle est la meilleure façon de procéder? Certains de mes pensées sont:

Option1

Réorganiser les chemins de la subversion (en utilisant svn move) à un format intermédiaire:

svnrepo/trunk/projectA 
svnrepo/trunk/projectB 
svnrepo/tags/projectA 
svnrepo/tags/projectB 
svnrepo/branches/projectA 
svnrepo/branches/projectB 

puis hg convertir sur le svnrepo/tronc. Cela va-t-il confondre l'importation de hg?

Option 2 hg convertir chacun des projets/tronc en repos hg séparés. Puis fusionnez-les en un seul repo hg (en utilisant hg init, hg pull -f projectA, etc). Je pense que cela va perdre les noms de branche et les étiquettes sur le premier projet importé.

Answer 1

En Mercurial, le stockage codebases indépendants dans le même référentiel est une mauvaise idée car il

• compliquent considérablement la fusion. Les fusions dépendront des modifications apportées à tous les projets, plutôt que du projet que vous essayez de fusionner.
• Cause de la surcharge de stockage et de paiement - Mercurial, pour autant que je sache, ne prend pas en charge l'extraction des sous-répertoires d'un référentiel. Vous devez brancher tous les projets à la fois.

La solution consiste à convertir votre référentiel Subversion unique en plusieurs référentiels Mercurial. La plupart des outils de conversion supportent cela.

Answer 2

Chaque projet doit être dans son propre référentiel Hg (pour pouvoir obtenir ou étiqueter uniquement un projet spécifique). Rappelez-vous que le répertoire que vous voyez dans Subversion (jonctions, balises, branches) n'existera pas dans un VCS moderne (D), où les branches et les balises sont des citoyens de première classe (méta-données directement gérées par l'outil), par opposition à simple répertoire résultant d'un copie bon marché (en SVN). Cela signifie que lorsque vous convertissez un référentiel SVN, vous ne devez pas stocker directement les répertoires "trunk", "tags" ou "branches" dans l'historique du repo Hg.

Vous devriez plutôt utiliser un tool like hgsubversion pour importer votre dépôt SVN (comme "repo/projectA") dans un repo Hg dédié au projetA. il conservera les balises et les branches du projet SVN orignal et les convertira en objets Hg.
De its documentation:

Toutes les mises à jour à l'aide de hgpullsvn sont faites dans la branche nommée du dernier composant de l'URL SVN (par exemple, Si l'URL SVN est svn://server/myproj/branches/feature-ZZZ, hgpullsvn va créer et utiliser la branche nommée « feature-ZZZ »)

---

Si vous ne voulez pas « convertir » mais « synchronisation », tonfa recommande hgsubversion, bien qu'il « est actuellement dans un état de flux en raison de refactoring lourd ":

est à l'heure actuelle pas prêt à l'emploi de la production. Vous ne devriez l'utiliser que si vous êtes prêt à le pirater, et allez plonger dans les internes de Mercurial et/ou Subversion.

Depuis hgsvn permettent également une synchronisation par hgpushsvn et hgpullsvn ... Je veux rester avec hgsvn pour l'instant.