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

https://stackoverflow.com/questions/79165

09-06-2019
|

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 telle que:

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, ni à une seule commande. 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.

La solution

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 contient une bonne section d’exemples:

$ git svn --help

Autres conseils

Créez un fichier utilisateur (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 le fichier 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 référentiel Git dans dest_dir-tmp et commencera à extraire le référentiel SVN. Notez que & Quot; - stdlayout & Quot; flag implique que vous avez le " trunk /, branches /, tags / " Mise en page SVN. Si votre disposition diffère, familiarisez-vous avec les --tags, --branches, --trunk options (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 &"; il est tout à fait normal qu'elle puisse rester bloquée longtemps après l'initialisation du nouveau référentiel. Vous verrez éventuellement 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 trunk fichier, puis:

cd dest_dir-tmp
git svn fetch

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

git svn fetch

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

git branch -r

Si vous souhaitez conserver d'autres branches distantes dans votre référentiel, vous souhaitez créer manuellement une branche locale pour chacune d'elles. (Ignorer 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 balises sont importées sous forme de 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 & Quot; v1 & Quot;

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 é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

Proprement Migrez 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’auteurs de commit Subversion avec les auteurs de 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 & # 8217; êtes sur un Mac, vous pouvez obtenir git-svn à partir de MacPorts en installant git-core +svn.

Si votre référentiel Subversion est sur le même ordinateur que votre référentiel Git souhaité, alors vous pouvez utiliser cette syntaxe pour l'étape d'initialisation, sinon tous les mêmes:

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

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

Je suggère de se familiariser avec Git avant d'essayer d'utiliser git-svn de manière constante, 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 jusqu'où vous souhaitez importer les révisions:

git svn fetch -r42

(ou simplement & "; git svn fetch &" pour tous les révs)

En fait, tout récupérer 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 votre référentiel SVN est cloné localement, vous pouvez le transférer dans un référentiel Git centralisé pour faciliter la collaboration.

Créez d'abord 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 succursales distantes:

Premier message explicatif: " branches distantes 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 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

Ensuite, vous obtiendrez le référentiel Git dans svn_repos / .git et pourrez le cloner ou continuer à utiliser Subversion et ce nouveau référentiel Git ensemble: 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. tant que vous en avez besoin (pour vos outils de construction déjà configurés, par exemple).

J'espère que ça aide!

Voir la page d'accueil de git-svn . En particulier, regardez sous & "Exemples de base &":

Suivi et contribution à un projet entier géré par Subversion (complet avec une malle, des étiquettes et des branches):

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

Pro Git 8.2 l’explique: http://git-scm.com/book / fr / Git-and-Other-Systems-Migration de Git

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

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 , mama. git-svn me rend Écran bleu de la mort . Juste constamment. Et git-svn m'ennuie avec le & Git- nom de fichier de Git long " erreur fatale.

ÉTAPES

1. Télécharger SubGit

2. préparer les commandes de migration et de mise à jour.

Supposons que nous le fassions pour Windows (le portage sous Linux est simple).
Dans le répertoire d'installation bin d'un sous-composant (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

Le " start " La commande est facultative ici (Windows). Cela permettra de voir les erreurs au démarrage et de laisser un shell ouvert après la fin du sous-jeu.

Vous pouvez ajouter ici les paramètres supplémentaires similaires à git-svn . J'utilise uniquement - default-domain myCompanyDomain.com pour corriger le domaine de l'adresse e-mail 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 & "; Cartographie des auteurs &"; Donc, je ne fais plus rien.

(Si vous souhaitez migrer des balises telles que des branches ou que votre SVN comporte plusieurs dossiers de branches / balises, vous pouvez envisager d'utiliser le sous-compte plus détaillé 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 à l'aide de la commande / du fichier de mise à jour suivant.
Je ne conseille pas de faire cela pour les grands dépôts. J'ai reçu & Quot; exception Java + Windows insuffisante en mémoire & Quot;.

Conseil n ° 3 : il est préférable de créer une copie de votre référentiel de résultats.

Contenu d'un fichier / commande de mise à jour:

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

Vous pouvez l'exécuter autant de fois que vous le souhaitez pour obtenir les derniers commits de l'équipe sur votre référentiel Git.

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

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

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

C'est tout.
Vous pouvez mettre à jour votre référentiel Git à partir de SVN à tout moment, en tout temps, 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.

Transférez votre référentiel Git local vers un référentiel Git distant

Est-ce votre cas? Allons-y.

Configurez vos télécommandes

Exécuter:

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

Préparez l'envoi initial de votre immense 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 cela:

git config --global http.postBuffer 1073741824

524288000 - 500 Mo 1073741824 - 1 Go, etc.

Corrigez votre problèmes de certificat . Si votre serveur Git utilise un certificat cassé.

J'ai désactivé les certificats .

Votre serveur Git peut également avoir un limite de quantité de demandes à corriger .

Pousser toutes les migrations dans le référentiel Git distant de l'équipe.

Exécuter avec un Git local:

git push origin --mirror

( origine de git push '*: *' pour les anciennes versions de Git)

Si vous obtenez les éléments suivants: erreur: impossible de générer git: aucun fichier ni 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 toutes vos balises et les pousser. Ou, ou, ou ...

mise en pension

Pour les cas compliqués, reconditionnez-vous 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 fait état de conversions réussies d'anciens référentiels, telles que Emacs et FreeBSD .

L’outil semble vise une conversion presque parfaite (par exemple, la conversion de fichiers SVN). svn:ignore propriétés sur .gitignore fichiers) 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 reposurgeon ligne de commande, veillez à lire l'excellent Guide de migration DVCS qui décrit pas à pas le processus de conversion.

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 votre authors.txt, entre autres.

Vous devez installer

git
git-svn

Copié à partir de ce lien http://john.albin.net/git/ convertir-subversion-à-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 & # 8217; ont des données beaucoup plus riches, mais dans le plus simple, l'auteur du commet doit avoir un nom et un e-mail répertoriés. 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 extraction Subversion locale, exécutez la commande suivante:

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

Cela récupérera tous les messages du journal, supprimera les noms d'utilisateur, éliminera les noms d'utilisateur en double, triera les noms d'utilisateur et les placera dans un & # 8220; authors-transform.txt & # 8221; fichier. Maintenant, éditez chaque ligne du fichier. Par exemple, convertir:

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

Ceci effectuera la transformation standard git-svn (à l'aide du fichier authors-transform.txt que vous avez créé à l'étape 1) et placera le référentiel git dans le répertoire & # 8220; ~ / temp & # 8221; dossier dans 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 fichier .gitignore à l'aide de:

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 adaptez sa branche par défaut à svn & # 8217; s & # 8220; trunk & # 8221; nom de la branche.

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. Renommez & # 8220; trunk & # 8221; branchez sur & # 8220; maître & # 8221;

Votre branche de développement principale s'appellera & # 8220; trunk & # 8221; qui correspond au nom qu'il était dans Subversion. Vous & # 8217; voudrez le renommer en standard & # 8217; de Git & # 8220; maître & # 8221; branche 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 branches très courtes dans Git de la forme & # 8220; tags / name & # 8221 ;. Vous & # 8217; 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 & # 8217; ne vous inquiétez pas; votre shell unix fournira un > invite secondaire de la commande extra-longue commençant par git pour chaque référence.

GitHub dispose désormais d'une fonctionnalité permettant de importer à partir d'un référentiel SVN . Je n'ai jamais essayé, cependant.

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 présentation classique avec une présentation de répertoire trunk / branches / tags (SVN ne fait absolument rien pour appliquer ce type de présentation).

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 tel que GitHub, seul le courrier électronique correspondant suffit).

Ensuite, disposez du git svn clone. le référentiel svn à 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 également accélérer le processus. De même, si pour une raison quelconque ce processus est interrompu, vous pouvez le 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. C’est peut-être le seul moyen si votre répertoire est entièrement situé à la racine du référentiel, lorsque j’ai essayé pour la dernière fois, git svn clone simplement refusé de procéder à une extraction.

Vous pouvez aussi le faire en utilisant git. Pour <=> utilisez simplement le répertoire que vous souhaitez mettre dans une branche git.

Après avoir exécuté

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

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

J'ai posté un guide étape par étape ( ici ) pour convertir svn en git, y compris la conversion de balises svn en balises git et de branches svn pour en branches 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 branches_subdir -r aRevisionNumber svn_url gitreponame

2) récupérer les 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) mise à jour de la branche principale

git svn rebase

4) Créez 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) Placez un référentiel à 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 souhaitez plus de détails, lisez mon post . ou me demander.

Nous pouvons utiliser git svn clone les commandes 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 à pousser. 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

L’utilitaire svn2git supprime les efforts manuels liés aux branches et aux balises.

Installez-le à l'aide de la commande sudo gem install svn2git. Après cela, exécutez la commande ci-dessous.

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

Vous pouvez maintenant 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 balises, évidemment, svn2git vous fera gagner beaucoup de temps et c’est pourquoi je l’aime mieux que les commandes natives. C'est un très bon emballage pour les commandes natives <=>.

Pour un exemple complet, consultez mon entrée de blog .

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

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

Je recommande vivement cette petite série de captures d'écran que je viens de découvrir. L'auteur vous explique 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. Goto File - & Gt; Nouveau / Cloner puis procédez comme suit:

Entrez l'URL du SVN distant en tant que & "Chemin source / URL &".
Entrez vos informations d'identification à l'invite.
Entrez l'emplacement du dossier local en tant que & "Chemin de destination &".
Donnez-lui un nom.
Dans les options avancées, sélectionnez " Git " à partir du menu déroulant dans & "Créer local" référentiel 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.

Allez maintenant dans le référentiel - > Paramètres du référentiel et ajouter les nouveaux détails du référentiel distant. Supprimez le SVN distant si vous le souhaitez (je l’ai fait par l’option & "Éditer le fichier de configuration &";

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

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

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

Procédure de migration de SVN vers GitLab

Configuration

SVN est hébergé chez svn.domain.com.au.
SVN est accessible via http (les autres protocoles devraient fonctionner).
GitLab est hébergé chez 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 avec ssh git@git.domain.com.au).
- Le projet favourite-project est créé dans le users.txt espace de noms.
Le fichier username = First Last <address@domain.com.au> contient les informations utilisateur pertinentes, un utilisateur par ligne, de la forme username, où git svn clone est 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).

Versions

version subversion 1.6.17 (r1128011)
git version 1.9.1
GitLab version 7.2.1 ff1633f
serveur Ubuntu 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 ça! Rechargez la page du projet dans l’interface utilisateur Web de GitLab et vous verrez tous les commits et fichiers maintenant répertoriés.

Notes

S'il existe des utilisateurs inconnus, la commande cd favourite-project s'arrête. Dans ce cas, la mise à jour git svn fetch, trunk et tags se poursuivront à partir de leur point d'arrêt.
La disposition standard branches - trunk/ - tags/ du référentiel SVN est requise.
L'URL SVN donnée à la commande branches/ s'arrête au niveau immédiatement supérieur à <=>, <=> et <=>.
La commande <=> produit beaucoup de résultats, y compris des avertissements en haut; J'ai ignoré les avertissements.

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

Un processus typique:

configurer le repo git
travaillez sur différents fichiers
décide de vérifier une partie du travail, en utilisant git
décide de svn-dcommit
obtenir le redouté & "; ne peut pas commettre avec un index sale &"; Erreur.

La solution (requiert 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 poussera vers GitHub.

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

En environ 30 lignes de script, il: clone utilisant git SVN, crée un fichier .gitignore à partir de propriétés SVN :: ignore, insère dans un référentiel git simple, renomme le tronc SVN en maître, convertit les balises SVN en balises git et à 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 brisé 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!

I & # 180; m sur une machine Windows et a créé un petit lot pour transférer un référentiel SVN avec l'historique (mais sans branches) vers un référentiel GIT en appelant simplement

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

Peut-être que tout le monde peut l'utiliser. Il crée un dossier TMP, vérifie le dépôt SVN avec git, ajoute la nouvelle origine et la repousse ... 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 utilisateur tels que

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

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 en SVN au format suivant:

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

Ce schéma est également populaire et pris en charge:

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

Chaque projet sera synchronisé par son nom:

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 .

utiliser 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 de l'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.

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

Installer svn2git
Menu Démarrer - > Tous les programmes - & Gt; Ruby - & Gt; Démarrer une invite de commande avec Ruby
Tapez ensuite & # 8220; gem install svn2git & # 8221; 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

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

SVN (/ Project_components) trunk - > Git Master SVN (/ Project_components) branches - & Gt; Branches Git Balises SVN (/ Project_components) - & Gt; Tags Git

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

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 référentiel avec environ 4000 commits, et après quatre jours pour mon ami!

Plusieurs réponses ici se réfèrent à https://github.com/nirvdrum/svn2git , mais pour les grands les dépôts cela peut être lent. J'ai essayé d'utiliser https://github.com/svn-all-fast-export/ svn2git à la place 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 quelques minutes, là où l'autre script a passé des heures.

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és sous Windows.

Prérequis:

git sous Windows (je l'ai déjà utilisée) https://git-scm.com/
svn avec les outils de la console installés (j'ai utilisé la tortue svn)
Fichier de vidage de votre référentiel SVN. svnadmin dump /path/to/repository > repo_name.svn_dump

Étapes pour atteindre l'objectif final (déplacez 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, placez 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 simplement utiliser le 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'avons-nous?

Permet de consulter notre référentiel local:

git log

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

Vous avez donc maintenant un référentiel 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 la commande tags car mon rapport n'a pas de tags.

Bonne chance!

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

git svn clone --no-metadata --trunk = SomeFolder1 / SomeFolder2 / SomeFolder3 / MyModule http: // svnhost: port / repo_root_folder / MyModule_temp - UNE C: \ cheetah \ svn \ authors-transform.txt
clone git MyModule_temp MyModule
cd MyModule
git flow init
origine de git set-url remote https: //userid@stashhost/stm/xyzxyz/MyModule.git
maître d'origine git push -u
développer git push -u origine

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

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow