Comment migrer un référentiel SVN avec historique vers un nouveau référentiel Git?

J’ai lu le manuel de Git, la FAQ, le cours accéléré de Git – SVN, etc.

Dépôt SVN dans: svn://myserver/path/to/svn/repos

Dépôt Git dans: git://myserver/path/to/git/repos

 git-do-the-magic-svn-import-with-history \ svn://myserver/path/to/svn/repos \ git://myserver/path/to/git/repos 

Je ne m’attends pas à ce que ce soit aussi simple, et je ne m’attends pas à ce que ce soit une seule commande. Mais je m’attends à ce qu’il n’essaie pas d’expliquer quoi que ce soit – juste pour dire quelles mesures prendre compte tenu de cet exemple.

La magie:

 $ git svn clone http://svn/repo/here/trunk 

Git et SVN fonctionnent très différemment. Vous devez apprendre Git, et si vous voulez suivre les changements depuis SVN en amont, vous devez apprendre git-svn . La page de manuel de git-svn contient de bons exemples:

 $ git svn --help 

Créez un fichier d’utilisateur (ie users.txt ) pour mapper les utilisateurs SVN sur Git:

 user1 = First Last Name  user2 = First Last Name  ... 

Vous pouvez utiliser cette ligne unique pour créer un modèle à partir de votre référentiel SVN existant:

 svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt 

SVN s’arrêtera s’il trouve un utilisateur SVN manquant dans le fichier. Mais après cela, vous pouvez mettre à jour le fichier et le ramasser là où vous l’avez laissé.

Maintenant, extrayez les données SVN du référentiel:

 git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp 

Cette commande créera un nouveau repository Git dans dest_dir-tmp et commencera à extraire le référentiel SVN. Notez que le drapeau “–stdlayout” implique que vous avez la disposition SVN commune “trunk /, twigs /, tags /”. Si votre disposition diffère, familiarisez-vous avec les --tags , --twigs , --trunk (en général git svn help ).

Tous les protocoles courants sont autorisés: svn:// , http:// , https:// . L’URL doit cibler le référentiel de base, quelque chose comme http://svn.mycompany.com/myrepo/repository . Cela ne doit pas inclure /trunk , /tag ou /twigs .

Notez qu’après l’exécution de cette commande, il semble très souvent que l’opération soit “bloquée / gelée”, et il est tout à fait normal qu’elle puisse restr bloquée longtemps après l’initialisation du nouveau référentiel. Finalement, vous verrez alors les messages de journal qui indiquent que la migration est en cours.

Notez également que si vous omettez l’indicateur --no-metadata , Git appenda des informations sur la révision SVN correspondante au message de validation (par exemple, git-svn-id: svn://svn.mycompany.com/myrepo/@ )

Si un nom d’utilisateur est introuvable, mettez à jour votre fichier users.txt puis:

 cd dest_dir-tmp git svn fetch 

Vous devrez peut-être répéter cette dernière commande plusieurs fois, si vous avez un grand projet, jusqu’à ce que tous les validations Subversion aient été récupérées:

 git svn fetch 

Une fois terminé, Git extraira la ligne réseau SVN dans une nouvelle twig. Toutes les autres twigs sont configurées comme des télécommandes. Vous pouvez voir les autres twigs SVN avec:

 git branch -r 

Si vous souhaitez conserver d’autres twigs distantes dans votre référentiel, vous souhaitez créer une twig locale pour chacune d’entre elles manuellement. (Sautez le coffre / le maître.) Si vous ne le faites pas, les twigs ne seront pas clonées dans la dernière étape.

 git checkout -b local_branch remote_branch # It's OK if local_branch and remote_branch are the same name 

Les balises sont imscopes en tant que twigs. Vous devez créer une twig locale, créer une balise et supprimer la twig pour les avoir comme balises dans Git. Pour le faire avec l’étiquette “v1”:

 git checkout -b tag_v1 remotes/tags/v1 git checkout master git tag v1 tag_v1 git branch -D tag_v1 

Clonez votre repository GIT-SVN dans un repository Git propre:

 git clone dest_dir-tmp dest_dir rm -rf dest_dir-tmp cd dest_dir 

Les twigs locales que vous avez créées précédemment à partir de twigs distantes n’auront été copiées qu’en tant que twigs distantes dans le nouveau référentiel cloné. (Sautez le tronc / maître.) Pour chaque twig que vous souhaitez conserver:

 git checkout -b local_branch origin/remote_branch 

Enfin, supprimez la télécommande de votre référentiel Git propre qui pointe vers le référentiel temporaire maintenant supprimé:

 git remote rm origin 

Migrez proprement votre référentiel Subversion dans un référentiel Git . Tout d’abord, vous devez créer un fichier qui mappe vos noms d’auteurs de validation Subversion avec les valideurs Git, disons ~/authors.txt :

 jmaddox = Jon Maddox  bigpappa = Brian Biggs  

Ensuite, vous pouvez télécharger les données Subversion dans un repository Git:

 mkdir repo && cd repo git svn init http://subversion/repo --no-metadata git config svn.authorsfile ~/authors.txt git svn fetch 

Si vous êtes sur un Mac, vous pouvez obtenir git-svn partir de MacPorts en installant git-core +svn .

Si votre référentiel de subversion se trouve sur le même ordinateur que le référentiel git souhaité, vous pouvez utiliser cette syntaxe pour l’étape init, sinon tout de même:

 git svn init file:///home/user/repoName --no-metadata 

J’ai utilisé le script svn2git et fonctionne comme un charme! https://github.com/nirvdrum/svn2git

Je suggère de devenir à l’aise avec Git avant d’essayer d’utiliser git-svn constamment, c’est-à-dire de garder SVN comme référentiel centralisé et d’utiliser Git localement.

Cependant, pour une migration simple avec tout l’historique, voici les quelques étapes simples:

Initialiser le repo local:

 mkdir project cd project git svn init http://svn.url 

Indiquez à quelle distance vous souhaitez commencer à importer des révisions:

 git svn fetch -r42 

(ou juste “git svn fetch” pour tous les tours)

Allez chercher tout depuis:

 git svn rebase 

Vous pouvez vérifier le résultat de l’importation avec Gitk. Je ne sais pas si cela fonctionne sous Windows, cela fonctionne sur OSX et Linux:

 gitk 

Lorsque votre référentiel SVN est cloné localement, vous pouvez le transférer vers un référentiel Git centralisé pour faciliter la collaboration.

Commencez par créer votre repo distant vide (peut-être sur GitHub ?):

 git remote add origin git@github.com:user/project-name.git 

Ensuite, vous pouvez éventuellement synchroniser votre twig principale pour que l’opération pull fusionne automatiquement le maître distant avec votre maître local, lorsque les deux contiennent de nouveaux éléments:

 git config branch.master.remote origin git config branch.master.merge refs/heads/master 

Après cela, vous pourriez vouloir essayer mon propre outil git_remote_branch , qui aide à gérer les twigs distantes:

Premier message explicatif: ” Branches distantes de Git ”

Suivi de la version la plus récente: “Il est temps de collaborer avec git_remote_branch ”

Il existe une nouvelle solution pour une migration fluide de Subversion vers Git (ou pour les utiliser simultanément): SubGit ( http://subgit.com/ ).

Je travaille sur ce projet moi-même. Nous utilisons SubGit dans nos référentiels – certains de mes coéquipiers utilisent Git et certains Subversion et jusqu’à présent, cela fonctionne très bien.

Pour migrer de Subversion vers Git avec SubGit, vous devez exécuter:

 $ subgit install svn_repos ... TRANSLATION SUCCESSFUL 

Après cela, vous obtiendrez le repository Git dans svn_repos / .git et vous pourrez le cloner ou continuer à utiliser Subversion et ce nouveau repository Git: SubGit s’assurera que les deux sont toujours synchronisés.

Si votre repository Subversion contient plusieurs projets, plusieurs repositorys Git seront créés dans le répertoire svn_repos / git. Pour personnaliser la traduction avant de l’exécuter, procédez comme suit:

 $ subgit configure svn_repos $ edit svn_repos/conf/subgit.conf (change mapping, add authors mapping, etc) $ subgit install svn_repos 

Avec SubGit, vous pouvez migrer vers Git pur (pas git-svn) et commencer à l’utiliser tout en conservant Subversion aussi longtemps que vous en avez besoin (pour vos outils de construction déjà configurés, par exemple).

J’espère que cela t’aides!

Voir la page de manuel officielle de git-svn . En particulier, regardez sous “Exemples de base”:

Suivi et consortingbution à tout un projet géré par Subversion (complet avec un tronc, des tags et des twigs):

 # Clone a repo (like git clone): git svn clone http://svn.foo.org/project -T trunk -b twigs -t tags 

SubGit (vs écran bleu de la mort)

 subgit import --svn-url url://svn.serv/Bla/Bla directory/path/Local.git.Repo 

C’est tout

+ Pour mettre à jour depuis SVN, un référentiel Git créé par la première commande.

 subgit import directory/path/Local.git.Repo 

J’ai utilisé un moyen de migrer instantanément vers Git pour un énorme référentiel.
Bien sûr, vous avez besoin de préparation.
Mais vous ne pouvez pas arrêter le processus de développement, du tout.

Voici mon chemin

Ma solution ressemble à:

  • Migrer SVN vers un repository Git
  • Mettez à jour le repository Git juste avant le passage de l’équipe .

La migration prend beaucoup de temps pour un grand repository SVN.
Mais la mise à jour de la migration terminée ne prend que quelques secondes.

Bien sûr, j’utilise SubGit , maman. git-svn me fait écran bleu de la mort . Juste constamment. Et git-svn m’ennuie avec l’erreur fatale du ” nom de fichier trop long ” de Git.

PAS

1. Télécharger SubGit

2. Préparez la migration et la mise à jour des commandes.

Disons que nous le faisons pour Windows (il est sortingvial de porter sur Linux).
Dans le répertoire d’installation de SubGit (subgit-2.XX \ bin), créez deux fichiers .bat.

Contenu d’un fichier / commande pour la migration:

 start subgit import --svn-url url://svn.serv/Bla/Bla directory/path/Local.git.Repo 

La commande “start” est facultative ici (Windows). Il permettra de voir les erreurs au démarrage et laissera un shell ouvert après l’achèvement du SubGit.

Vous pouvez append ici d’ autres parameters similaires à git-svn . J’utilise uniquement –default-domain myCompanyDomain.com pour corriger le domaine de l’adresse électronique des auteurs SVN.
J’ai la structure standard du repository SVN (trunk / twigs / tags) et nous n’avons pas eu de problèmes avec le “mapping” des auteurs. Donc je ne fais plus rien.

(Si vous souhaitez migrer des balises telles que des twigs ou que votre SVN possède plusieurs dossiers de twigs / balises, vous pouvez envisager d’utiliser l’ approche SubTit plus détaillée)

Astuce 1 : Utilisez –minimal-revision YourSvnRevNumber pour voir rapidement comment les choses se résument (une sorte de débogage). Il est particulièrement utile de voir les noms d’auteurs ou les e-mails résolus.
Ou limiter la profondeur de l’historique de migration.

Astuce 2 : La migration peut être interrompue ( Ctrl + C ) et restaurée en exécutant la prochaine commande / fichier de mise à jour.
Je ne conseille pas de le faire pour les grands repositorys. J’ai reçu “Out of memory Java + Windows exception”.

Astuce 3 : Mieux vaut créer une copie de votre référentiel nu.

Contenu d’un fichier / commande pour la mise à jour:

 start subgit import directory/path/Local.git.Repo 

Vous pouvez l’exécuter autant de fois que vous souhaitez obtenir les commits de la dernière équipe dans votre référentiel Git.

Attention! Ne touchez pas votre repository nu (création de twigs par exemple).
Vous allez prendre la prochaine erreur fatale:

Erreur irrécupérable: ne sont pas synchronisés et ne peuvent pas être synchronisés … Traduction des révisions de Subversion vers Git commits …

3. Exécutez la première commande / fichier. Ça va prendre du temps pour un grand repository. 30 heures pour mon humble repository.

C’est tout
Vous pouvez mettre à jour votre repository Git à partir de SVN à tout moment en exécutant le second fichier / commande. Et avant de passer votre équipe de développement à Git.
Cela ne prendra que quelques secondes.



Il y a une autre tâche utile.

Poussez votre repository Git local vers un référentiel Git distant

Est-ce votre cas? Continuons.

  1. Configurez vos télécommandes

Courir:

 $ git remote add origin url://your/repo.git 
  1. Préparez-vous à l’envoi initial de votre énorme référentiel Git local vers un référentiel distant

Par défaut, votre Git ne peut pas envoyer de gros morceaux. fatal: l’extrémité distante a raccroché de manière inattendue

Courons pour ça:

 git config --global http.postBuffer 1073741824 

524288000 – 500 Mo 1073741824 – 1 Go, etc.

Corrigez vos problèmes de certificates locaux. Si votre serveur GIT utilise un certificate cassé.

J’ai des certificates désactivés.

De même, votre serveur Git peut avoir des limitations de montant de demande devant être corrigées .

  1. Poussez toute la migration vers le référentiel Git distant de l’équipe.

Exécuter avec un Git local:

 git push origin --mirror 

( git push origin ‘*: *’ pour les anciennes versions de Git)

Si vous obtenez ce qui suit: error: impossible de générer git: Pas de tel fichier ou répertoire … Pour moi, la recréation complète de mon référentiel résout cette erreur (30 heures). Vous pouvez essayer les commandes suivantes

 git push origin --all git push origin --tags 

Ou essayez de réinstaller Git ( inutile pour moi ). Ou vous pouvez créer des twigs de tous vos tags et les pousser. Ou, ou, ou …

Ce guide sur le site Web d’Atlassian est l’un des meilleurs que j’ai trouvé:

https://www.atlassian.com/git/migration

Cet outil – https://bitbucket.org/atlassian/svn-migration-scripts – est également très utile pour générer vos auteurs.txt, entre autres.

repérage

Pour les cas compliqués, le repositionnement par Eric S. Raymond est l’outil de choix. Outre SVN, il prend en charge de nombreux autres systèmes de contrôle de version via le format d’ fast-export , ainsi que CVS . L’auteur rapporte des conversions réussies d’anciens référentiels tels qu’Emacs et FreeBSD .

L’outil vise apparemment une conversion presque parfaite (comme la conversion des propriétés svn:ignore propriétés de .gitignore fichiers .gitignore ), même pour les mises en page de référentiels difficiles avec une longue histoire. Dans de nombreux cas, d’autres outils peuvent être plus faciles à utiliser.

Avant de vous lancer dans la documentation de la ligne de commande du reposurgeon , assurez-vous de lire l’excellent guide de migration DVCS qui passe en revue le processus de conversion pas à pas.

Une réponse quelque peu étendue utilisant simplement git, SVN et bash. Il comprend des étapes pour les référentiels SVN qui n’utilisent pas la mise en page conventionnelle avec une disposition de répertoire trunk / twigs / tags (SVN ne fait absolument rien pour appliquer ce type de disposition).

Utilisez d’abord ce script bash pour parsingr votre référentiel SVN pour les différentes personnes qui ont consortingbué et pour générer un modèle pour un fichier de mappage:

 #!/usr/bin/env bash authors=$(svn log -q | grep -e '^r' | awk 'BEGIN { FS = "|" } ; { print $2 }' | sort | uniq) for author in ${authors}; do echo "${author} = NAME "; done 

Utilisez-le pour créer un fichier authors où vous mappez les noms d’utilisateur svn avec les noms d’utilisateur et les e-mails définis par vos développeurs à l’aide des propriétés git config user.name et user.email (notez que pour un service comme GitHub, seul un e-mail correspondant suffit).

Ensuite, git svn clone le repository svn dans un repository git, en lui expliquant le mappage:

git svn clone --authors-file=authors --stdlayout svn://example.org/Folder/projectroot

Cela peut prendre énormément de temps, car git svn vérifie individuellement chaque révision pour chaque tag ou twig existant. (notez que les tags dans SVN ne sont que de véritables twigs, donc ils se retrouvent comme tels dans Git). Vous pouvez accélérer cela en supprimant les anciens tags et les anciennes twigs dont vous n’avez pas besoin.

L’exécuter sur un serveur du même réseau ou sur le même serveur peut également accélérer le processus. De plus, si pour une raison quelconque ce processus est interrompu, vous pouvez le reprendre en utilisant

git svn rebase --continue

Dans beaucoup de cas, vous avez fini ici. Mais si votre repository SVN a une mise en page non conventionnelle où vous avez simplement un répertoire dans SVN que vous voulez placer dans une twig git, vous pouvez faire quelques étapes supplémentaires.

Le plus simple est de créer un nouveau référentiel SVN sur votre serveur qui respecte les conventions et d’utiliser svn copy pour placer votre répertoire dans un tronc ou une twig. C’est peut-être la seule façon si votre répertoire est à la racine du repository, quand j’ai essayé la dernière fois, git svn simplement refusé de faire une vérification.

Vous pouvez aussi le faire en utilisant git. Pour git svn clone utilisez simplement le répertoire que vous voulez placer dans une twig git.

Après la course

 git branch --set-upstream master git-svn git svn rebase 

Notez que cela nécessite Git 1.7 ou supérieur.

Vous devez installer

 git git-svn 

Copié à partir de ce lien http://john.albin.net/git/convert-subversion-to-git .

1. Récupérer une liste de tous les committers Subversion

Subversion répertorie simplement le nom d’utilisateur pour chaque commit. Les commits de Git ont des données beaucoup plus riches, mais dans sa forme la plus simple, l’auteur du commit doit avoir un nom et un email listés. Par défaut, l’outil git-svn listera simplement le nom d’utilisateur SVN dans les champs auteur et email. Mais avec un peu de travail, vous pouvez créer une liste de tous les utilisateurs SVN et leur nom Git et leurs emails correspondants. Cette liste peut être utilisée par git-svn pour transformer de simples noms d’utilisateur svn en véritables committers Git.

À partir de la racine de votre extraction Subversion locale, exécutez cette commande:

 svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt 

Cela va récupérer tous les messages du journal, extraire les noms d’utilisateur, éliminer tous les noms d’utilisateur en double, sortinger les noms d’utilisateurs et les placer dans un fichier “auteurs-transform.txt”. Maintenant, éditez chaque ligne du fichier. Par exemple, convertissez:

 jwilkins = jwilkins  

dans ceci:

 jwilkins = John Albin Wilkins  

2. Clone le repository Subversion en utilisant git-svn

 git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp 

Cela fera la transformation standard de git-svn (en utilisant le fichier auteurs-transform.txt que vous avez créé à l’étape 1) et placez le repository git dans le dossier “~ / temp” de votre répertoire personnel.

3. Convertissez svn: ignorez les propriétés à .gitignore

Si votre svn repo utilisait svn: ignore les propriétés, vous pouvez facilement convertir ceci en un fichier .gitignore en utilisant:

 cd ~/temp git svn show-ignore > .gitignore git add .gitignore git commit -m 'Convert svn:ignore properties to .gitignore.' 

4. Poussez le référentiel dans un référentiel git

Tout d’abord, créez un repository nu et créez sa twig par défaut correspondant au nom de twig «trunk» de svn.

 git init --bare ~/new-bare.git cd ~/new-bare.git git symbolic-ref HEAD refs/heads/trunk 

Poussez ensuite le référentiel temporaire vers le nouveau référentiel nu.

 cd ~/temp git remote add bare ~/new-bare.git git config remote.bare.push 'refs/remotes/*:refs/heads/*' git push bare 

Vous pouvez maintenant supprimer en toute sécurité le repository ~ / temp.

5. Renommez la twig “trunk” en “master”

Votre twig de développement principale portera le nom de «trunk» correspondant au nom de Subversion. Vous voudrez le renommer en twig standard de Git en utilisant:

 cd ~/new-bare.git git branch -m trunk master 

6. Nettoyer les twigs et les étiquettes

git-svn fait toutes les balises Subversions dans des twigs très courtes dans Git de la forme “tags / nom”. Vous voudrez convertir toutes ces twigs en tags Git réels en utilisant:

 cd ~/new-bare.git git for-each-ref --format='%(refname)' refs/heads/tags | cut -d / -f 4 | while read ref do git tag "$ref" "refs/heads/tags/$ref"; git branch -D "tags/$ref"; done 

Cette étape nécessitera un peu de saisie. 🙂 Mais ne vous inquiétez pas votre shell unix fournira une invite> secondaire pour la commande extra-longue qui commence par git for-each-ref.

GitHub a maintenant une fonctionnalité à importer depuis un repository SVN . Je n’ai jamais essayé, cependant.

TortoiseGit fait ça. voir cet article de blog: http://jimmykeen.net/articles/03-nov-2012/how-migrate-from-svn-to-git-windows-using-tortoise-clients

Oui, je sais que répondre avec des liens n’est pas magnifique mais c’est une solution, hein?

Nous pouvons utiliser les commandes git svn clone comme ci-dessous.

  • svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors.txt

La commande ci-dessus créera le fichier auteurs à partir des commits SVN.

  • svn log --stop-on-copy

La commande ci-dessus vous donnera le premier numéro de révision lorsque votre projet SVN sera créé.

  • git svn clone -r:HEAD --no-minimize-url --stdlayout --no-metadata --authors-file authors.txt

La commande ci-dessus créera le repository Git en local.

Le problème est qu’il ne convertira pas les twigs et les tags en push. Vous devrez les faire manuellement. Par exemple ci-dessous pour les twigs:

 $ git remote add origin https://github.com/pankaj0323/JDProjects.git $ git branch -a * master remotes/origin/MyDevBranch remotes/origin/tags/MyDevBranch-1.0 remotes/origin/trunk $$ git checkout -b MyDevBranch origin/MyDevBranch Branch MyDevBranch set up to track remote branch MyDevBranch from origin. Switched to a new branch 'MyDevBranch' $ git branch -a * MyDevBranch master remotes/origin/MyDevBranch remotes/origin/tags/MyDevBranch-1.0 remotes/origin/trunk $ 

Pour les tags:

 $git checkout origin/tags/MyDevBranch-1.0 Note: checking out 'origin/tags/MyDevBranch-1.0'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any twigs by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 3041d81... Creating a tag $ git branch -a * (detached from origin/tags/MyDevBranch-1.0) MyDevBranch master remotes/origin/MyDevBranch remotes/origin/tags/MyDevBranch-1.0 remotes/origin/trunk $ git tag -a MyDevBranch-1.0 -m "creating tag" $git tag MyDevBranch-1.0 $ 

Poussez maintenant le maître, les twigs et les balises vers le référentiel git distant.

 $ git push origin master MyDevBranch MyDevBranch-1.0 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (14/14), 2.28 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To https://github.com/pankaj0323/JDProjects.git * [new branch] master -> master * [new branch] MyDevBranch -> MyDevBranch * [new tag] MyDevBranch-1.0 -> MyDevBranch-1.0 $ 

utilitaire svn2git

L’ utilitaire svn2git supprime les efforts manuels avec les twigs et les balises.

Installez-le en utilisant la commande sudo gem install svn2git . Après cela, exécutez la commande ci-dessous.

  • $ svn2git --authors authors.txt --revision

Maintenant, vous pouvez lister les twigs, les tags et les pousser facilement.

 $ git remote add origin https://github.com/pankaj0323/JDProjects.git $ git branch -a MyDevBranch * master remotes/svn/MyDevBranch remotes/svn/trunk $ git tag MyDevBranch-1.0 $ git push origin master MyDevBranch MyDevBranch-1.0 

Imaginez que vous ayez 20 twigs et balises, évidemment svn2git vous fera gagner beaucoup de temps et c’est pourquoi je l’aime mieux que les commandes natives. C’est une belle enveloppe autour de la commande native git svn clone .

Pour un exemple complet, référez-vous à mon entrée de blog .

J’ai posté un guide étape par étape ( ici ) pour convertir svn in en git, y compris la conversion des balises svn en balises git et des twigs svn en twigs git.

Version courte:

1) clonez svn à partir d’un numéro de révision spécifique. (le numéro de révision doit être le plus ancien que vous souhaitez migrer)

 git svn clone --username=yourSvnUsername -T trunk_subdir -t tags_subdir -b twigs_subdir -r aRevisionNumber svn_url gitreponame 

2) Récupérer des données svn. Cette étape est celle qui prend le plus de temps.

 cd gitreponame git svn fetch 

répéter git svn fetch jusqu’à la fin sans erreur

3) mettre à jour la twig principale

 git svn rebase 

4) Créer des twigs locales à partir de twigs svn en copiant des références

 cp .git/refs/remotes/origin/* .git/refs/heads/ 

5) convertir les balises svn en balises git

 git for-each-ref refs/remotes/origin/tags | sed 's#^.*\([[:xdigit:]]\{40\}\).*refs/remotes/origin/tags/\(.*\)$#\2 \1#g' | while read p; do git tag -m "tag from svn" $p; done 

6) Placer un repository dans un meilleur endroit comme github

 git remotes add newrepo git@github.com:aUser/aProjectName.git git push newrepo refs/heads/* git push --tags newrepo 

Si vous voulez plus de détails, lisez mon post ou demandez moi.

Je recommande vivement cette courte série de screencasts que je viens de découvrir. L’auteur vous guide à travers les opérations de base et présente des utilisations plus avancées.

Si vous utilisez SourceTree, vous pouvez le faire directement depuis l’application. Allez à Fichier -> Nouveau / Clone, puis procédez comme suit:

  1. Entrez l’URL SVN distante en tant que “chemin d’access / URL”.
  2. Entrez vos informations d’identification lorsque vous y êtes invité.
  3. Entrez l’emplacement du dossier local en tant que “chemin de destination”.
  4. Donne lui un nom.
  5. Dans les options avancées, sélectionnez “Git” dans la liste déroulante “Créer un référentiel local de type”.
  6. Vous pouvez éventuellement spécifier une révision à cloner.
  7. Hit Clone.

Ouvrez le référentiel dans SourceTree et vous verrez que vos messages de validation ont également été migrés.

Maintenant, allez dans Repository -> Repository Settings et ajoutez les nouveaux détails de repo à distance. Supprimez la télécommande SVN si vous le souhaitez (je l’ai fait via l’option “Modifier le fichier de configuration”).

Poussez le code sur le nouveau repo distant lorsque vous êtes prêt et codez librement.

Par ailleurs, la commande git-stash est une aubaine lorsque vous essayez de vous connecter avec git-svn dcommits.

Un processus typique:

  1. mettre en place go repo
  2. faire du travail sur différents fichiers
  3. décider de vérifier une partie du travail en utilisant git
  4. décider de svn-dcommit
  5. obtenir le redoutable “ne peut pas commettre avec un index sale” erreur.

La solution (nécessite git 1.5.3+):

 git stash; git svn dcommit ; git stash apply 

Voici un script shell simple sans dépendances qui convertira un ou plusieurs référentiels SVN en git et les transmettra à GitHub.

https://gist.github.com/NathanSweet/7327535

Dans environ 30 lignes de script, il: clone en utilisant git SVN, crée un fichier .gitignore à partir de SVN :: ignore les propriétés, pousse dans un repository nu, renomme la ligne SVN en maître, convertit les balises SVN en balises git et la transmet à GitHub tout en préservant les tags.

J’ai eu beaucoup de mal à déplacer une douzaine de référentiels SVN de Google Code vers GitHub. Cela n’a pas aidé que j’ai utilisé Windows. Ruby était de toutes sortes cassé sur mon ancienne boîte Debian et le faire fonctionner sous Windows était une blague. Les autres solutions ne fonctionnaient pas avec les chemins Cygwin. Même une fois que quelque chose a fonctionné, je ne pouvais pas comprendre comment faire apparaître les balises sur GitHub (le secret est –follow-tags).

Au final, j’ai concocté deux scripts simples et courts, liés ci-dessus, et cela fonctionne très bien. La solution n’a pas besoin d’être plus compliquée que ça!

Pour les utilisateurs de GitLab , j’ai expliqué comment j’ai migré de SVN ici:

https://gist.github.com/leftclickben/322b7a3042cbe97ed2af

Étapes pour migrer de SVN vers GitLab

Installer

  • SVN est hébergé sur svn.domain.com.au .
  • SVN est accessible via http (d’autres protocoles devraient fonctionner).
  • GitLab est hébergé sur git.domain.com.au et:
    • Un groupe est créé avec la dev-team espace de noms.
    • At least one user account is created, added to the group, and has an SSH key for the account being used for the migration (test using ssh git@git.domain.com.au ).
    • The project favourite-project is created in the dev-team namespace.
  • The file users.txt contains the relevant user details, one user per line, of the form username = First Last , where username is the username given in SVN logs. (See first link in References section for details, in particular answer by user Casey).

Versions

  • subversion version 1.6.17 (r1128011)
  • git version 1.9.1
  • GitLab version 7.2.1 ff1633f
  • Ubuntu server 14.04

Commandes

 bash git svn clone --stdlayout --no-metadata -A users.txt http://svn.domain.com.au/svn/repository/favourite-project cd favourite-project git remote add gitlab git@git.domain.com.au:dev-team/favourite-project.git git push --set-upstream gitlab master 

C’est tout! Reload the project page in GitLab web UI and you will see all commits and files now listed.

Remarques

  • If there are unknown users, the git svn clone command will stop, in which case, update users.txt , cd favourite-project and git svn fetch will continue from where it stopped.
  • The standard trunktagstwigs layout for SVN repository is required.
  • The SVN URL given to the git svn clone command stops at the level immediately above trunk/ , tags/ and twigs/ .
  • The git svn clone command produces a lot of output, including some warnings at the top; I ignored the warnings.

I just wanted to add my consortingbution to the Git community. I wrote a simple bash script which automates the full import. Unlike other migration tools, this tool relies on native git instead of jGit. This tool also supports repositories with a large revision history and or large blobs. It’s available via github:

https://github.com/onepremise/SGMS

This script will convert projects stored in SVN with the following format:

 /trunk /Project1 /Project2 /twigs /Project1 /Project2 /tags /Project1 /Project2 

This scheme is also popular and supported as well:

 /Project1 /trunk /twigs /tags /Project2 /trunk /twigs /tags 

Each project will get synchronized over by project name:

 Ex: ./migration https://svnurl.com/basepath project1 

If you wish to convert the full repo over, use the following syntax:

 Ex: ./migration https://svnurl.com/basepath . 

I´m on a windows machine and made a small Batch to transfer a SVN repo with history (but without twigs) to a GIT repo by just calling

transfer.bat http://svn.my.address/svn/myrepo/trunk https://git.my.address/orga/myrepo

Perhaps anybody can use it. It creates a TMP-folder checks out the SVN repo there with git and adds the new origin and pushes it… and deletes the folder again.

 @echo off SET FROM=%1 SET TO=%2 SET TMP=tmp_%random% echo from: %FROM% echo to: %TO% echo tmp: %TMP% pause git svn clone --no-metadata --authors-file=users.txt %FROM% %TMP% cd %TMP% git remote add origin %TO% git push --set-upstream origin master cd .. echo delete %TMP% ... pause rmdir /s /q %TMP% 

You still need the users.txt with your user-mappings like

 User1 = User One  

Effectively using Git with Subversion is a gentle introduction to git-svn. For existing SVN repositories, git-svn makes this super easy. If you’re starting a new repository, it’s vastly easier to first create an empty SVN repository and then import using git-svn than it is going in the opposite direction. Creating a new Git repository then importing into SVN can be done, but it is a bit painful, especially if you’re new to Git and hope to preserve the commit history.

Download the Ruby installer for Windows and install the latest version with it. Add Ruby executables to your path.

  • Install svn2git
  • Start menu -> All programs -> Ruby -> Start a command prompt with Ruby
  • Then type “gem install svn2git” and enter

    Migrate Subversion repository

  • Open a Ruby command prompt and go to the directory where the files are to be migrated

    Then svn2git http://[domain name]/svn/ [repository root]

  • It may take few hours to migrate the project to Git depends on the project code size.

  • This major step helps in creating the Git repository structure as mentioned below.

    SVN (/Project_components) trunk –> Git master SVN (/Project_components) twigs –> Git twigs SVN (/Project_components) tags –> Git tags

Create the remote repository and push the changes.

GitHub has an importer. Once you’ve created the repository, you can import from an existing repository, via its URL. It will ask for your credentials if applicable and go from there.

As it’s running it will find authors, and you can simply map them to users on GitHub.

I have used it for a few repositories now, and it’s pretty accurate and much faster too! It took 10 minutes for a repository with ~4000 commits, and after it took my friend four days!

Several answers here refer to https://github.com/nirvdrum/svn2git , but for large repositories this can be slow. I had a try using https://github.com/svn-all-fast-export/svn2git instead which is a tool with exactly the same name but was used to migrate KDE from SVN to Git.

Slightly more work to set it up but when done the conversion itself for me took minutes where the other script spent hours.

There are different methods to achieve this goal. I’ve sortinged some of them and found really working one with just git and svn installed on Windows OS.

Prerequirejsites:

  1. git on windows (I’ve used this one) https://git-scm.com/
  2. svn with console tools installed (I’ve used tortoise svn)
  3. Dump file of your SVN repository. svnadmin dump /path/to/repository > repo_name.svn_dump

Steps to achieve final goal (move all repository with history to a git, firstly local git, then remote)

  1. Create empty repository (using console tools or tortoiseSVN) in directory REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER , put dumpfile.dump into REPO_NAME_PARENT_FOLDER

  2. svnadmin load REPO_NAME_FOLDER < dumpfile.dump Wait for this operation, it may be long

  3. This command is silent, so open second cmd window : svnserve -d -R --root REPO_NAME_FOLDER Why not just use file:///...... ? Cause next command will fail with Unable to open ... to URL: , thanks to the answer https://stackoverflow.com/a/6300968/4953065

  4. Create new folder SOURCE_GIT_FOLDER

  5. cd SOURCE_GIT_FOLDER
  6. git svn clone svn://localhost/ Wait for this operation.

Finally, what do we got?

Lets check our Local repository :

 git log 

See your previous commits? If yes - okay

So now you have fully functional local git repository with your sources and old svn history. Now, if you want to move it to some server, use the following commands :

 git remote add origin https://fullurlpathtoyourrepo/reponame.git git push -u origin --all # pushes up the repo and its refs for the first time git push -u origin --tags # pushes up any tags 

In my case, I've dont need tags command cause my repo dont have tags.

Bonne chance!

Converting svn submodule/folder ‘MyModule’ into git with history without tags nor twigs.

To retain svn ignore list use the above comments after step 1