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

Question

J'ai lu le manuel Git, la FAQ, le cours intensif Git - SVN, etc., et ils expliquent tous ceci et cela, mais vous ne trouverez nulle part une instruction simple comme:

Référentiel 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 qu'il s'agisse d'une commande unique. Mais je ne m'attends pas à ce qu’il n’essaye pas d’expliquer quoi que ce soit, mais simplement de dire quelles étapes prendre compte tenu de cet exemple.

jfm3 · Accepted Answer

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 souhaitez suivre les modifications apportées par SVN en amont, vous devez apprendre git-svn. La page de manuel git-svn contient une bonne section exemples:

$ git svn --help

cmcginty · Answer

Créez un fichier d'utilisateurs (c'est-à-dire users.txt) pour mapper les utilisateurs SVN sur Git:

user1 = First Last Name <email@address.com> user2 = First Last Name <email@address.com> ...

Vous pouvez utiliser cette méthode 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 qui ne figure pas dans le fichier. Mais après cela, vous pouvez mettre à jour le fichier et récupérer où vous vous êtes arrêté.

Extrayez maintenant 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 va créer un nouveau référentiel Git dans dest_dir-tmp et commencer à extraire le référentiel SVN. Notez que le drapeau "--stdlayout" implique que vous avez la même disposition "trunk /, branches /, tags /" SVN. Si votre mise en page diffère, familiarisez-vous avec les options --tags, --branches, --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, par exemple http://svn.mycompany.com/myrepo/repository . Cela doit ne pas inclure /trunk, /tag ou /branches.

Notez qu'après l'exécution de cette commande, il semble très souvent que l'opération est "suspendue/gelée", et il est tout à fait normal qu'elle puisse rester bloquée longtemps après l'initialisation du nouveau référentiel. Finalement, vous verrez ensuite des messages de journalisation indiquant que la migration est en cours.

Notez également que si vous omettez l'indicateur --no-metadata, Git ajoutera des informations sur la révision SVN correspondante au message de validation (c'est-à-dire git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>).

Si aucun nom d'utilisateur n'est trouvé, mettez à jour votre fichier users.txt:

cd dest_dir-tmp git svn fetch

Si vous avez un grand projet, vous devrez peut-être répéter cette dernière commande plusieurs fois jusqu'à ce que tous les commits de Subversion aient été récupérés:

git svn fetch

Une fois terminé, Git extraira le SVN trunk dans une nouvelle branche. Toutes les autres branches sont configurées comme télécommandes. Vous pouvez voir les autres branches SVN avec:

git branch -r

Si vous souhaitez conserver d'autres branches distantes dans votre référentiel, vous voulez créer manuellement une branche locale pour chacune d'elles. (Ignorez le tronc/le maître.) Si vous ne le faites pas, les branches ne seront pas clonées à 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 tags sont importés en tant que branches. Vous devez créer une branche locale, créer une balise et supprimer la branche pour les avoir en tant que balises dans Git. Pour le faire avec la balise "v1":

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

Clonez votre référentiel GIT-SVN dans un référentiel Git propre:

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

Les branches locales que vous avez créées précédemment à partir de branches distantes auront uniquement été copiées en tant que branches distantes dans le nouveau référentiel cloné. (Ignorer le tronc/le maître.) Pour chaque branche 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

Eugene Yokota · Answer

Migrez proprement votre référentiel Subversion vers un référentiel Git . Tout d’abord, vous devez créer un fichier qui mappe vos noms d’auteur de commit Subversion avec des auteurs Git, par exemple ~/authors.txt:

jmaddox = Jon Maddox <jon@gmail.com> bigpappa = Brian Biggs <bigpappa@gmail.com>

Vous pouvez ensuite télécharger les données Subversion dans un référentiel 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 Subversion se trouve sur le même ordinateur que votre référentiel git souhaité, vous pouvez utiliser cette syntaxe pour l'étape init, sinon, restez identique:

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

Thiago Le&#227;o Moreira · Answer

J'ai utilisé le script svn2git et fonctionne comme un charme.

webmat · Answer

Je suggère de se familiariser avec Git avant d’essayer d’utiliser constamment git-svn, c’est-à-dire de conserver SVN en tant que référentiel centralisé et d’utiliser Git localement.

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

Initialiser le référentiel 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 révs)

En fait, tout chercher 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, mais sous OSX et Linux:

gitk

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

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

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

Ensuite, synchronisez éventuellement votre branche principale pour que l'opération d'extraction 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 voudrez peut-être essayer mon propre outil git_remote_branch, qui aide à gérer les branches distantes:

Premier article explicatif: " Git remote branches "

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

Alexander Kitaev · Answer

Il existe une nouvelle solution pour une migration en douceur de Subversion vers Git (ou pour l’utilisation simultanée des deux): SubGit .

Je travaille sur ce projet moi-même. Nous utilisons SubGit dans nos référentiels - certains de mes coéquipiers utilisent Git et d'autres 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 référentiel Git dans svn_repos/.git et vous pourrez le cloner ou simplement continuer à utiliser Subversion et ce nouveau référentiel Git: SubGit veillera à ce que les deux soient toujours synchronisés.

Si votre référentiel Subversion contient plusieurs projets, plusieurs référentiels 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 compilation déjà configurés, par exemple).

J'espère que cela t'aides!

EfForEffort · Answer

Voir l’officiel git-svn manpage . En particulier, regardez sous "Exemples de base":

Suivi et contribution à un projet entier géré par Subversion (avec un tronc, des tags et des branches):

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

kdahlhaus · Answer

Pro Git 8.2 l'explique: http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git

it3xl · Answer

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 à partir de 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 créer 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 le SVN vers un référentiel Git
Mettez à jour le référentiel Git juste avant le passage de l'équipe à .

La migration prend beaucoup de temps pour un grand référentiel 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 " nom de fichier trop long " de Git.

ÉTAPES

1. téléchargement de la sous-partie

2. Préparez les commandes de migration et de mise à jour.

Disons que nous le faisons pour Windows (le portage sous Linux est trivial).
Dans le répertoire d'installation d'un sous-ensemble bin (subgit-2.X.X\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). Cela permettra de voir les erreurs au début et de laisser un shell ouvert après la fin du sous-script.

Vous pouvez ajouter ici paramètres supplémentaires similaires à git-svn . J'utilise seulement - default-domain myCompanyDomain.com pour corriger le domaine de l'adresse de messagerie des auteurs SVN.
J'ai la structure standard du référentiel SVN (trunk/branches/tags) et nous n'avons pas eu de problèmes avec le "mapping des auteurs". Alors je ne fais plus rien.

(Si vous souhaitez migrer des balises telles que des branches ou que votre SVN possède plusieurs dossiers de branches/balises, vous pouvez envisager d'utiliser le plus détaillé SubGit approche )

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 courriels résolus.
Ou pour limiter la profondeur de l'historique de migration.

Astuce 2 : la migration peut être interrompue (Ctrl + C) et restaurée en exécutant la commande/le fichier de mise à jour suivant.
Je ne conseille pas de faire cela pour les grands dépôts. J'ai reçu "Exception de mémoire insuffisante Java + Windows".

Astuce 3 : Il est préférable de créer une copie de votre référentiel de résultats.

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 nécessaire pour obtenir les derniers commits de l'équipe sur votre référentiel Git.

Attention! Ne touchez pas à votre référentiel nu (création de branches par exemple).
Vous allez prendre la prochaine erreur fatale:

Erreur irrécupérable: désynchronisée et ne peut pas être synchronisée ... Traduire les révisions Subversion en Git commet ...

3. Exécutez la première commande/fichier. Cela prendra un loooong pour un grand dépôt. 30 heures pour mon humble référentiel.

C'est tout.
Vous pouvez mettre à jour votre référentiel Git à partir de SVN à tout moment en exécutant le deuxième fichier/commande. Et avant de transférer votre équipe de développement vers Git.
Cela ne prendra que quelques secondes.

Il y a encore une tâche utile.

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

Est-ce votre cas? Continuons.

Configurez vos télécommandes

Courir:

$ git remote add Origin url://your/repo.git

Préparez 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 votre problème local problèmes de certificat . Si votre serveur Git utilise un certificat cassé.

J'ai désactivé certificats .

De plus, votre serveur Git peut avoir un les limitations du montant de la requête doivent être corrigées .

Transférer toutes les migrations vers le référentiel Git distant de l'équipe.

Courir avec un Git local:

git Push Origin --mirror

( Origine Push Git '*: *' pour les anciennes versions de Git)

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

git Push Origin --all git Push Origin --tags

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

krlmlr · Answer

Reposant

Pour les cas compliqués, le chirurgien 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 fast-export, ainsi que CVS . L'auteur rapporte des conversions réussies d'anciens référentiels tels que Emacs et FreeBSD .

L'outil apparemment vise à une conversion presque parfaite (comme la conversion des propriétés svn:ignore de SVN en fichiers .gitignore) même pour les dispositions de référentiel difficiles avec un long historique. Dans de nombreux cas, d'autres outils pourraient être plus faciles à utiliser.

Avant de plonger dans la documentation de la ligne de commande reposurgeon, assurez-vous de lire l'excellent guide de migration DVCS , qui décrit le processus de conversion étape par étape.

Andrew B · Answer

Ce guide sur le site Web d'atlassian est l'un des meilleurs que j'ai trouvés:

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

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

Valarpirai · Answer

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 plus simple expression, l'auteur doit avoir un nom et un email. Par défaut, l'outil git-svn ne listera que 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, ainsi que le nom et les courriels correspondants de Git. Git-svn peut utiliser cette liste pour transformer des noms d'utilisateur simples en svn en committers Git appropriés.

À la racine de votre commande 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, supprimer les noms d'utilisateur, éliminer tout nom d'utilisateur en double, trier les noms d'utilisateur et les placer dans un fichier "authors-transform.txt". Maintenant, éditez chaque ligne du fichier. Par exemple, convertissez:

jwilkins = jwilkins <jwilkins>

dans ceci:

jwilkins = John Albin Wilkins <johnalbin@example.com>

2. Cloner le référentiel 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 authors-transform.txt que vous avez créé à l'étape 1) et placez le référentiel git dans le dossier "~/temp" de votre répertoire personnel.

3. Convertissez les propriétés svn: ignore en .gitignore

Si votre référentiel svn utilisait les propriétés svn: ignore, vous pouvez facilement le convertir 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. Transférer un référentiel dans un référentiel Git nu

Tout d’abord, créez un référentiel nu et assurez-vous que sa branche par défaut correspond au nom de la branche "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 référentiel ~/temp.

5. Renommer la branche "trunk" en "master"

Votre branche de développement principale sera nommée "trunk", ce qui correspond au nom qu’elle était dans Subversion. Vous voudrez le renommer en branche "principale" standard de Git en utilisant:

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

6. Nettoyer les branches et les tags

git-svn transforme toutes les balises Subversions en très courtes branches dans Git de la forme "balises/nom". Vous voudrez convertir toutes ces branches en balises Git réelles 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 frappe. :-) Mais ne vous inquiétez pas; votre shell unix fournira une invite secondaire pour la commande extra-longue commençant par git for-each-ref.

thoutbeckers · Answer

Une réponse un peu plus longue utilisant simplement git, SVN et bash. Il inclut des étapes pour les référentiels SVN qui n'utilisent pas la disposition conventionnelle avec une disposition de répertoire trunk/branches/tags (SVN ne fait absolument rien pour appliquer ce type de disposition).

Commencez par utiliser ce script bash pour analyser votre référentiel SVN à la recherche des différentes personnes ayant contribué 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 <USER@DOMAIN>"; done _

Utilisez-le pour créer un fichier authors dans lequel vous mappez les noms d'utilisateur svn aux noms d'utilisateur et aux adresses électroniques définis par vos développeurs à l'aide de git config propriétés _user.name_ et _user.email_ (notez que pour un service comme GitHub, seul un email correspondant suffit).

Ensuite, ayez git svn clonez le référentiel svn dans un référentiel git en lui indiquant 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érifiera chaque révision pour chaque balise ou branche existante. (notez que les tags dans SVN sont vraiment des branches, ils finissent donc comme tels dans Git). Vous pouvez accélérer le processus en supprimant les anciennes balises et les branches inutiles dans SVN.

L'exécuter sur un serveur du même réseau ou sur le même serveur peut aussi vraiment accélérer le processus. En outre, 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 terminé. Mais si votre référentiel SVN a une présentation non conventionnelle dans laquelle vous souhaitez simplement placer un répertoire dans SVN, vous pouvez effectuer quelques étapes supplémentaires.

Le plus simple consiste simplement à créer un nouveau référentiel SVN sur votre serveur qui respecte les conventions et à utiliser _svn copy_ pour placer votre répertoire dans un tronc ou une branche. Cela pourrait être le seul moyen si votre répertoire est entièrement à la racine du référentiel, lorsque j'ai essayé pour la dernière fois de procéder à cette _git svn_ simplement refusé de procéder à une extraction.

Vous pouvez aussi le faire en utilisant git. Pour _git svn clone_, utilisez simplement le répertoire que vous souhaitez mettre dans une branche git.

Après avoir couru

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

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

webmat · Answer

GitHub a maintenant une fonctionnalité pour importer depuis un référentiel SVN . Je n'ai jamais essayé, cependant.

Pablo Belaustegui · Answer

J'ai posté un guide étape par étape ( here ) pour convertir svn en git, y compris la conversion des balises svn en balises git et des branches svn pour les branches git.

Version courte:

1) clone 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 branches_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ète git svn fetch jusqu'à la fin sans erreur

3) obtenir la branche principale mise à jour

git svn rebase

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

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

5) convertir les tags svn en tags 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) Mettre un dépôt 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.

Pankaj · Answer

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

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

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

svn log --stop-on-copy <SVN_URL>

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

git svn clone -r<SVN_REV_NO>:HEAD --no-minimize-url --stdlayout --no-metadata --authors-file authors.txt <SVN_URL>

La commande ci-dessus créera le référentiel Git en local.

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

$ 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 branches 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 branches et les balises dans 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

svn2git l'utilitaire supprime les efforts manuels avec les branches et les tags.

Installez-le en utilisant la commande Sudo gem install svn2git. Après cette exécution en-dessous de la commande.

$ svn2git <SVN_URL> --authors authors.txt --revision <SVN_REV_NO>

Maintenant, vous pouvez lister les branches, 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 avez 20 branches et tags, évidemment svn2git vous fera gagner beaucoup de temps et c’est pourquoi je l’aime mieux que les commandes natives. C'est un wrapper Nice autour de la commande native git svn clone.

Pour un exemple complet, reportez-vous à my entrée de blog .

CAD bloke · Answer

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

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

leftclickben · Answer

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

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

Étapes à suivre pour migrer de SVN vers GitLab

Installer

SVN est hébergé chez svn.domain.com.au.
SVN est accessible via http (les autres protocoles devraient fonctionner).
GitLab est hébergé sur git.domain.com.au et:
- Un groupe est créé avec l’espace de nom dev-team.
- Au moins un compte d'utilisateur est créé, ajouté au groupe et possède une clé SSH pour le compte utilisé pour la migration (test utilisant ssh git@git.domain.com.au).
- Le projet favourite-project est créé dans l'espace de noms dev-team.
Le fichier users.txt contient les informations utilisateur pertinentes, un utilisateur par ligne, de la forme username = First Last <address@domain.com.au>, où username représente le nom d'utilisateur indiqué dans les journaux SVN. (Voir le premier lien dans la section Références pour plus de détails, en particulier sur la réponse de l'utilisateur Casey).

Les versions

Subversion version 1.6.17 (r1128011)
version git 1.9.1
GitLab version 7.2.1 ff1633f
Serveur Ubuntu 14.04

Les 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 ça! Rechargez la page du projet dans l'interface utilisateur Web de GitLab et vous verrez tous les commits et les fichiers maintenant répertoriés.

Remarques

S'il y a des utilisateurs inconnus, la commande git svn clone s'arrête. Dans ce cas, la mise à jour users.txt, cd favourite-project et git svn fetch continuera à partir de l'endroit où elle s'est arrêtée.
La disposition standard trunk-tags-branches pour le référentiel SVN est requise.
L'URL SVN attribué à la commande git svn clone s'arrête au niveau immédiatement supérieur à trunk/, tags/ et branches/.
La commande git svn clone génère beaucoup de résultats, y compris des avertissements en haut; J'ai ignoré les avertissements.

Craig Myles · Answer

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

Entrez l'URL SVN distante en tant que "Chemin source/URL".
Entrez vos informations d'identification lorsque vous y êtes invité.
Entrez l'emplacement du dossier local comme "chemin de destination".
Donne lui un nom.
Dans les options avancées, sélectionnez "Git" dans le menu déroulant de "Créer un référentiel local de type".
Vous pouvez éventuellement spécifier une révision à partir de laquelle cloner.
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 du repo distant. Supprimez la télécommande SVN si vous le souhaitez (je l’ai fait via l’option "Edit Config File".

Poussez le code dans le nouveau référentiel distant lorsque vous êtes prêt et codez librement.

ripper234 · Answer

Je recommande fortement cette courte série de screencasts je viens de découvrir. L'auteur vous explique les opérations de base et présente des utilisations plus avancées.

NateS · Answer

Voici un script Shell simple sans dépendances qui convertira un ou plusieurs référentiels SVN en git et les poussera vers GitHub.

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

Dans environ 30 lignes de script, il clone à l'aide de git SVN, crée un fichier .gitignore à partir de propriétés SVN :: ignore, insère un référentiel git vide, renomme le tronc SVN en maître, convertit les balises SVN en balises git, puis les transfère sur GitHub. tout en préservant les tags.

J'ai beaucoup souffert en déplaçant une douzaine de référentiels SVN de Google Code vers GitHub. Cela n'a pas aidé que j'ai utilisé Windows. Ruby était cassé de toutes sortes sur mon ancien ordinateur Debian et le faire fonctionner sous Windows était une blague. D'autres solutions n'ont pas fonctionné avec les chemins Cygwin. Même une fois que quelque chose fonctionnait, je ne pouvais pas trouver comment faire apparaître les tags sur GitHub (le secret est --follow-tags).

En fin de compte, j'ai bricolé 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!

Gregg Lind · Answer

De plus, la commande git-stash est une aubaine pour git avec git-svn dcommits.

Un processus typique:

mettre en place git repo
faire du travail sur différents fichiers
décide de vérifier une partie du travail, en utilisant git
décider de svn-dcommit
obtenir le redouté "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

cljk · Answer

Je suis sur une machine Windows et j'ai créé un petit lot pour transférer un dépôt SVN avec l'historique (mais sans branches) vers un dépôt GIT en appelant simplement

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

Peut-être que n'importe qui peut l'utiliser. Il crée un dossier TMP, vérifie le dépôt SVN avec git, ajoute le nouvel Origine et le pousse ... et supprime à nouveau le dossier.

@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%

Vous avez toujours besoin du fichier users.txt avec vos mappages d’utilisateur, comme

User1 = User One <u.1@xxx.com>

Jason Huntley · Answer

Je voulais juste ajouter ma contribution à la communauté Git. J'ai écrit un script bash simple qui automatise l'importation complète. Contrairement aux autres outils de migration, cet outil repose sur git natif au lieu de jGit. Cet outil prend également en charge les référentiels avec un historique de révision important et/ou des blobs volumineux. Il est disponible via github:

https://github.com/onepremise/SGMS

Ce script convertira les projets stockés dans SVN au format suivant:

/trunk /Project1 /Project2 /branches /Project1 /Project2 /tags /Project1 /Project2

Ce schéma est également populaire et supporté:

/Project1 /trunk /branches /tags /Project2 /trunk /branches /tags

Chaque projet sera synchronisé par nom de projet:

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

Si vous souhaitez convertir le référentiel complet, utilisez la syntaxe suivante:

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

Ruslan Makrenko · Answer

Il existe différentes méthodes pour atteindre cet objectif. J'en ai essayé quelques-unes et je trouve que ça marche vraiment avec juste git et svn installé sous Windows.

Conditions préalables:

Étapes pour atteindre l'objectif final (déplacer tous les référentiels avec l'historique vers un git, d'abord git local, puis distant)

Créez un référentiel vide (à l'aide des outils de la console ou de tortoiseSVN) dans le répertoire REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER, mettez dumpfile.dump dans REPO_NAME_PARENT_FOLDER.
svnadmin load REPO_NAME_FOLDER < dumpfile.dump Attendez cette opération, elle peut être longue
Cette commande est silencieuse, ouvrez donc la deuxième fenêtre de commande: svnserve -d -R --root REPO_NAME_FOLDER Pourquoi ne pas utiliser simplement fichier: /// ......? La prochaine commande échouera avec Unable to open ... to URL:, grâce à la réponse https://stackoverflow.com/a/6300968/4953065
Créer un nouveau dossier SOURCE_GIT_FOLDER
cd SOURCE_GIT_FOLDER
git svn clone svn: // localhost/Attendez cette opération.

Enfin, qu'est-ce qu'on a?

Permet de consulter notre référentiel local:

git log

Voir vos commits précédents? Si oui, d'accord

Alors maintenant, vous avez un dépôt git local entièrement fonctionnel avec vos sources et votre ancien historique svn. Maintenant, si vous voulez le déplacer sur un serveur, utilisez les commandes suivantes:

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

Dans mon cas, je n'ai pas besoin de balises, car mon référent n'a pas de balises.

Bonne chance!

Josh Benson · Answer

GitHub a un importateur. Une fois que vous avez créé le référentiel, vous pouvez importer à partir d'un référentiel existant, via son URL. Il vous demandera vos identifiants, le cas échéant, et partira de là.

Pendant son fonctionnement, il trouvera des auteurs et vous pourrez simplement les mapper aux utilisateurs sur GitHub.

Je l'ai utilisé pour quelques dépôts maintenant, et c'est assez précis et beaucoup plus rapide aussi! Cela a pris 10 minutes pour un dépôt avec environ 4000 commits, et après cela a pris quatre jours à mon ami!

burkestar · Answer

tiliser efficacement Git avec Subversion est une introduction douce à git-svn. Pour les référentiels SVN existants, git-svn facilite tout cela. Si vous démarrez un nouveau référentiel, il est beaucoup plus facile de créer d'abord un référentiel SVN vide, puis de l'importer à l'aide de git-svn que d'aller dans le sens opposé. Il est possible de créer un nouveau référentiel Git, puis d'importer dans SVN, mais c'est un peu pénible, surtout si vous débutez dans Git et que vous souhaitez préserver l'historique de validation.

Zitrax · Answer

Plusieurs réponses ici font référence à https://github.com/nirvdrum/svn2git , mais cela peut être lent pour les référentiels volumineux. J'ai essayé d'utiliser https://github.com/svn-all-fast-export/svn2git qui est un outil portant exactement le même nom mais ayant été utilisé pour migrer KDE de SVN vers Git.

Un peu plus de travail pour le configurer, mais une fois terminé, la conversion elle-même a pris pour moi quelques minutes, là où l'autre script a passé des heures.

Nanda · Answer

Téléchargez le programme d’installation Ruby pour Windows et installez-y la dernière version. Ajoutez Ruby _ exécutables à votre chemin.

Installer svn2git
Menu Démarrer -> Tous les programmes -> Ruby -> Lancer une commande avec invite Ruby
Puis tapez “gem install svn2git” et entrez

Migrer le référentiel Subversion
Ouvrez une invite de commande Ruby et accédez au répertoire dans lequel les fichiers doivent être migrés.

Puis svn2git http: // [domaine nom]/svn/[racine du référentiel]
La migration du projet vers Git peut prendre quelques heures selon la taille du code du projet.
Cette étape majeure aide à créer la structure de référentiel Git comme indiqué ci-dessous.

Tronc SVN (/ Project_components) -> Git master branches SVN (/ Project_components) -> branches Git Balises SVN (/ Project_components) -> balises Git

Créez le référentiel distant et transmettez les modifications.

Pedro Vicente · Answer

J'ai utilisé le script suivant pour lire un fichier texte contenant une liste de tous mes référentiels SVN et pour les convertir en Git, puis pour utiliser git clone --bare afin de le convertir en référentiel nu Git:

#!/bin/bash file="list.txt" while IFS= read -r repo_name do printf '%s
' "$repo_name" Sudo git svn clone --shared --preserve-empty-dirs --authors-file=users.txt file:///programs/svn/$repo_name Sudo git clone --bare /programs/git/$repo_name $repo_name.git Sudo chown -R www-data:www-data $repo_name.git Sudo rm -rf $repo_name done <"$file"

list.txt a le format suivant:

repo1_name repo2_name

Et users.txt a le format:

(no author) = Prince Rogers <prince.rogers.nelson@payesley.park.org>

www-data est l'utilisateur du serveur Web Apache. Une autorisation est nécessaire pour transmettre les modifications via HTTP.

PShetty · Answer

Conversion du sous-module/dossier 'MyModule' de svn en git avec historique sans balises ni branches.

Pour conserver la liste svn ignore, utilisez les commentaires ci-dessus après l'étape 1