créer un fichier d'utilisateurs (i.e. users.txt ) pour faire correspondre les utilisateurs SVN à Git:

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

vous pouvez utiliser cette doublure unique pour construire un modèle à partir de votre dépôt SVN existant:

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

SVN s'arrêtera s'il trouve un utilisateur SVN manquant qui ne se trouve pas dans le fichier. Mais après que vous pouvez mettre à jour le fichier et pick-up où vous l'avez laissé.

maintenant, retirez les données SVN du dépôt:

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

cette commande créera un nouveau dépôt Git dans dest_dir-tmp et commencera à tirer le dépôt SVN. Notez que le drapeau" --stdlayout "implique que vous avez la disposition commune" trunk/, branches/, tags/ " SVN. Si votre mise en page diffère, familiarisez-vous avec --tags , --branches , --trunk options (en général git svn help ).

tous les protocoles communs sont autorisés: svn:// , http:// , https:// . L'URL doit cibler le dépôt de base, quelque chose comme http://svn.mycompany.com/myrepo/repository . Qui doit être et non , y compris /trunk , /tag ou /branches .

notez qu'après avoir exécuté 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 dépôt. Finalement, vous verrez alors les messages de log qui indiquent qu'il est en train de migrer.

notez aussi que si vous omettez le drapeau --no-metadata , Git ajoutera des informations sur la révision SVN correspondante au message de propagation (i.e. git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID> )

si un nom d'utilisateur n'est pas trouvé, mettez à jour votre fichier users.txt puis:

cd dest_dir-tmp
git svn fetch

vous pourriez devoir répéter cette dernière commande plusieurs fois, si vous avez un grand projet, jusqu'à ce que toutes les propagations de Subversion aient été récupérées:

git svn fetch

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

git branch -r

si vous voulez garder d'autres branches distantes dans votre dépôt, vous voulez créer une branche locale pour chacune manuellement. (Sauter un tronc/master. Si vous ne le faites pas, les branches ne seront pas clonées à l'étape finale.

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

sont importées en tant que succursales. Vous devez créer une branche locale, créer une étiquette et supprimer la branche pour les avoir comme étiquettes 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 dépôt Git-SVN dans un dépôt 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 n'auront été copiées qu'en tant que branches distantes dans le nouveau dépôt cloné. (Sauter un tronc/master. Pour chaque branche que vous souhaitez conserver:

git checkout -b local_branch origin/remote_branch

enfin, retirez la télécommande de votre dépôt propre Git qui pointe vers le dépôt temporaire maintenant supprimé:

git remote rm origin

migrez proprement votre dépôt Subversion vers un dépôt Git . Tout d'abord, vous devez créer un fichier qui mappe les noms d'auteurs de Subversion vers les propagateurs Git, en disant ~/authors.txt :

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

ensuite, vous pouvez télécharger les données de Subversion dans un dépôt 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 de MacPorts en installant git-core +svn .

si votre le dépôt subversion est sur la même machine que le dépôt git désiré, vous pouvez alors utiliser cette syntaxe pour l'étape d'initialisation, 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 se mettre à l'aise avec Git avant d'essayer d'utiliser git-svn constamment, c'est-à-dire de garder SVN comme compte rendu centralisé et d'utiliser git localement.

Cependant, pour une migration simple avec toute l'histoire, voici les quelques étapes simples:

Initialiser le local repo:

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

Marquez jusqu'à quel point vous voulez commencer à importer des révisions:

git svn fetch -r42

(ou tout simplement "git svn fetch" pour tous revs)

extraire tout depuis:

git svn rebase

, Vous pouvez vérifier le résultat de l'importation avec Gitk. Je ne suis pas sûr que cela fonctionne sur Windows, il fonctionne sur OSX et Linux:

gitk

lorsque vous avez votre SVN repo cloné localement, vous pouvez le pousser à un repo git centralisé pour une collaboration plus facile.

créez D'abord votre rapport à distance vide (peut-être sur GitHub ?):

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

ensuite, synchronisez optionnellement votre branche principale de sorte que l'opération de traction fusionnera automatiquement le maître distant avec votre maître local, quand tous les deux contiennent de nouvelles choses:

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

après cela, vous pourriez être intéressé à essayer mon propre outil git_remote_branch , qui aide à traiter les branches éloignées:

premier poste explicatif: git remote branches

il existe une nouvelle solution pour la migration en douceur de Subversion vers Git (ou pour utiliser les deux simultanément): SubGit ( http://subgit.com / ).

je travaille moi-même sur ce projet. Nous utilisons SubGit dans nos dépôts - certains de mes coéquipiers utilisent Git et Subversion et jusqu'à présent cela fonctionne très bien.

pour passer de Subversion à Git avec SubGit vous devez exécuter:

$ subgit install svn_repos
...
TRANSLATION SUCCESSFUL 

après ça vous obtiendrez le dépôt Git dans svn_repos/.Git et may le clonent, ou continuent d'utiliser Subversion et ce nouveau dépôt Git ensemble: SubGit veillera à ce que les deux soient toujours synchronisés.

si votre dépôt Subversion contient plusieurs projets, plusieurs dépôts Git seront créés dans le répertoire svn_repos/git. Pour personnaliser la traduction avant de l'exécuter, faites ce qui suit:

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

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

Espérons que cette aide!

Voir "officiel git-svn man . En particulier, regardez sous "exemples de base":

suivi et contribution à L'ensemble d'un projet géré par Subversion (complet) avec un tronc, 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

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

sous-Git (vs Écran Bleu De La Mort)

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

c'est tout.

+ mettre à jour depuis SVN, un dépôt Git créé par la première commande.

subgit import  directory/path/Local.git.Repo

j'ai utilisé un moyen de migrer vers Git instantanément pour un grand dépôt.

Bien sûr que tu as besoin de préparation.

Mais vous ne pouvez pas arrêter le développement processus, à tous.

voici ma façon.

ma solution ressemble à:

• Migrer SVN pour un dépôt Git
• mettre à Jour le dépôt Git juste avant de l'équipe de commutation .

la Migration prend beaucoup de temps pour un grand dépôt SVN.

Mais la mise à jour de l'achèvement de la la migration ne dure que quelques secondes.

bien sûr que j'utilise SubGit , mama. git-svn me fait Écran Bleu De La Mort . Juste en permanence. Et git-svn m'ennuie avec le" nom de fichier trop long " erreur fatale.

ÉTAPES

1. Télécharger SubGit

2. préparer les commandes migrate et updating.

disons que nous le faisons pour Windows (c'est trivial de passer à Linux).

Dans le répertoire d'installation d'un sous-git bin (sous-git-2.X. X\bin), la création de deux .les 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 "Démarrer" est optionnelle ici (Windows). Il permettra de voir des erreurs sur démarrer et laisser un shell ouvert après l'achèvement de la sous-unité.

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 e-mail des auteurs SVN.

J'ai la structure standard du dépôt SVN (trunk/branches/tags) et nous n'avons pas eu de problèmes avec "authors mapping". Donc, je fais plus rien.

(si vous voulez migrer des balises comme branches ou votre SVN ont plusieurs dossiers branches/tags, Vous pouvez envisager d'utiliser le sous-Git plus verbeux approche )

Conseil 1 : utiliser --minimal-revision YourSvnRevNumber pour voir rapidement comment les choses se résorbent (une sorte de débogage). Particulièrement utile est de voir des noms d'auteur résolus ou des e-mails.

Ou à limiter la profondeur de l'histoire de la 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 ça pour de grands dépôts. J'ai reçu "de la mémoire Java+Windows exception".

Conseil 3 : mieux créer une copie de votre résultat nu référentiel.

contenu d'un fichier/Commande de mise à jour:

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

vous pouvez l'exécuter toutes les fois où vous voulez obtenir les dernières propagations de l'équipe vers votre dépôt Git.

attention! ne touchez pas à votre dépôt nu (création de branches par exemple).

Vous prendrez la prochaine erreur fatale:

erreur non récupérable: sont désynchronisés et ne peut pas être synchronisé ... Traduire les révisions de Subversion en git commits...

3. exécutez la première commande/Fichier. Ça prendra du temps pour un grand dépôt. 30 heures pour mon humble référentiel.

c'est tout.

Vous pouvez à tout moment mettre à jour votre dépôt Git à partir de SVN n'importe quand en lançant la commande second file/. Et avant de changer de votre équipe de développement à Git.

Ça va prendre quelques secondes.

il y a une autre tâche utile.

Pousser votre dépôt Git local à distance à un dépôt Git

est-ce votre affaire? Nous allons procéder.

1. configurer vos télécommandes

Run:

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

2. préparez-vous à l'envoi initial de votre énorme dépôt local Git vers un dépôt distant

par défaut votre Git ne peut pas envoyer de gros morceaux. fatal: L'extrémité distante accroché de façon inattendue

courons pour ça:

git config --global http.postBuffer 1073741824

524288000-500 MB 1073741824-1 GB, etc.

fixer votre local problèmes de certificat . Si votre git-server utilise un certificat défectueux.

j'ai désactivé certificats .

votre serveur Git peut aussi avoir une limitation du montant de la requête à corriger .

3. Pousser tous les migrations à l'équipe de dépôts Git distant.

Exécuter avec un Git local:

git push origin --mirror

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

Si vous obtenez le résultat suivant: erreur: impossible de se frayer git: Aucun fichier ou répertoire de ... Pour moi, la reconstitution complète de mon dépôt résout cette erreur (30 heures). Vous pouvez essayer les commandes suivantes

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

Ou d'essayer de réinstaller Git ( inutile pour moi ). Ou vous pouvez créer des branches à partir de toutes vos étiquettes et les pousser. Ou, ou, ou...

reposturgeon

pour les cas compliqués, repris par Eric S. Raymond est l'outil de choix. En plus de SVN, il prend en charge de nombreux autres systèmes de contrôle de version via le format fast-export , et aussi CVS . L'auteur rapporte des conversions réussies de dépôts anciens tels que Emacs et FreeBSD .

le l'outil vise apparemment une conversion quasi parfaite (telle que la conversion des propriétés svn:ignore de SVN en fichiers .gitignore ), même pour des configurations de dépôt difficiles avec une longue histoire. Pour de nombreux cas, d'autres outils peuvent être plus faciles à utiliser.

avant de plonger dans la documentation de la ligne de commande reposurgeon , assurez-vous de lire l'excellent DVCS migration guide qui passe en revue le processus de conversion étape par étape.

ce guide sur le site 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 choses.

Un peu étendus réponse en utilisant simplement git, SVN, et bash. Il inclut des étapes pour les dépôts SVN qui n'utilisent pas la disposition conventionnelle avec une disposition de répertoire trunk/branches/tags (SVN ne fait absolument rien pour imposer ce genre de disposition).

utilisez D'abord ce script bash pour scanner votre SVN repo pour les différentes personnes qui ont 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  }' | sort | uniq)
for author in ${authors}; do
  echo "${author} = NAME <USER@DOMAIN>";
done

utilisez ceci pour créer un authors fichier dans lequel vous associez svn usernames à usernames et email tel que défini par vos développeurs en utilisant git config propriétés user.name et user.email (notez que pour un service comme GitHub, il suffit d'avoir un email correspondant).

puis avoir git svn cloner le dépôt svn à un dépôt git, lui parler de la cartographie:

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

This peut prendre incroyablement longtemps, puisque git svn vérifiera individuellement chaque révision pour chaque étiquette ou branche qui existe. (notez que les tags dans SVN ne sont que des branches, donc ils finissent en tant que tels dans Git). Vous pouvez accélérer cela en enlevant les vieilles étiquettes et les branches dans SVN dont vous n'avez pas besoin.

exécuter ceci sur un serveur dans le même réseau ou sur le même serveur peut aussi vraiment accélérer cela. Aussi, si pour une raison quelconque ce processus est interrompu vous peut reprendre avec

git svn rebase --continue

Dans beaucoup de cas, vous avez fait ici. Mais si votre SVN repo a une mise en page non conventionnelle où vous avez simplement un répertoire dans SVN que vous voulez mettre dans une branche git, vous pouvez faire quelques pas supplémentaires.

le plus simple est de créer un nouveau SVN repo sur votre serveur qui suit la convention et utilise svn copy pour mettre votre répertoire dans le tronc ou une branche. Ce pourrait être le seul moyen si votre répertoire est tout le chemin à la racine du repo, quand j'ai essayé pour la dernière fois ce git svn a simplement refusé de faire une caisse.

vous pouvez également le faire en utilisant git. Pour git svn clone utilisez simplement le répertoire que vous voulez mettre dans une branche git.

Après la course

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

noter que cela exigeait Git 1.7 ou plus.

vous devez installer

git
git-svn

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

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

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

à partir de la racine de votre caisse Subversion locale, exécutez cette commande:

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

qui va saisir tous les messages de log, pluck sur le nom d'utilisateur, éliminez tout nom d'utilisateur dupliqué, triez les noms d'utilisateur et placez-les dans un "auteur-transformer.txt" un fichier. Maintenant, modifiez chaque ligne du fichier. Par exemple, convertir:

jwilkins = jwilkins <jwilkins>

dans ceci:

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

2. Cloner le dépôt Subversion en utilisant git-svn

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

cela fera la transformation standard git-svn (en utilisant les auteurs-transform.fichier txt que vous avez créé dans step 1) et placez le dépôt git dans le "~/temp" à l'intérieur de votre répertoire d'accueil.

3. Convertir les propriétés svn:ignore .gitignore

si votre SVN repo utilisait des propriétés svn:ignore, vous pouvez facilement les convertir en a.gitignore fichier à l'aide de:

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

4. Pousser référentiel à un simple dépôt git

tout d'abord, créer un dépôt nu et faire correspondre sa branche par défaut 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

puis pousser le dépôt temporaire vers le nouveau dépôt 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 dépôt ~/temp.

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

votre principale branche de développement s'appellera" trunk", ce qui correspond au nom qu'elle portait dans Subversion. Vous aurez envie de les renommer il Git standard "maître" de la branche à l'aide:

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

6. Nettoyer les branches et les étiquettes

git-svn fait de toutes les balises de subversion des branches très courtes en Git de la forme"tags/name". Vous voulez convertir toutes ces branches en véritables étiquettes Git 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 prendra un peu de Dactylographie. :- ) Mais, ne vous inquiétez pas, votre interpréteur de commandes unix fournira une invite secondaire pour l'extra-long de commande qui commence par git pour-chaque-réf.

GitHub a maintenant une fonctionnalité pour importer à partir D'un dépôt SVN . Je n'ai jamais essayé, si.

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

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

la commande ci-dessus va créer un fichier d'auteurs à partir de SVN commits.

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

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

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

La commande ci-dessus va créer le dépôt Git en local.

le problème est qu'il ne convertira pas les branches et les étiquettes à pousser. Vous devrez le faire manuellement. Par exemple ci-dessous pour les succursales:

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

pousse maintenant master, branches et tags vers le dépôt Git à distance.

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

svn2git utilitaire

svn2git utility supprime les efforts manuels avec les branches et les étiquettes.

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

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

Maintenant vous pouvez lister les branches, les étiquettes 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 j'aime mieux que les commandes natives. C'est une belle enveloppe autour de la commande natif git svn clone .

pour un exemple complet, référez-vous à mon blog entry .

TortoiseGit fait ceci. voir ce billet 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 splendide mais c'est une solution, hein?

j'ai posté un guide étape par étape ( ici ) pour convertir svn in en git, y compris convertir SVN tags en git tags et SVN branches en git branches.

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 voulez migrer)

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

2) chercher svn de données. Cette étape c'est celle qui prend le plus de temps.

cd gitreponame
git svn fetch

répéter git svn chercher jusqu'à ce que se termine sans erreur

3) obtenir la branche principale mise à jour

git svn rebase

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

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

5) convertissez les étiquettes svn en étiquettes git

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

6) Mettre un dépôt à 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 me poser des questions.

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

Si vous utilisez SourceTree vous pouvez le faire directement depuis l'application. Goto Fichier -> Nouveau/Clone puis effectuez les opérations suivantes:

1. entrez L'URL SVN distante comme"chemin / URL Source".
2. saisissez vos informations d'identification lorsqu'on vous le demande.
3. entrez l'emplacement du dossier local comme le"chemin de Destination".
4. Donnez-lui un nom.
5. Dans les options avancées, sélectionnez "Git" dans la liste déroulante dans "Créer des local référentiel de type".
6. Vous pouvez éventuellement spécifier une révision pour cloner.
7. Hit Clone.

ouvrez le dossier dans SourceTree et vous verrez que vos messages de propagation ont aussi été migrés.

maintenant, allez dans dépôt -> paramètres du dépôt et ajoutez les nouveaux détails du dépôt à distance. Supprimez la commande SVN remote si vous le souhaitez (Je l'ai fait via L'option "Modifier le fichier de configuration").

Poussez le code vers le nouveau repo à distance lorsque vous êtes prêt et codez librement.

comme autre mise à part, la commande git-stash est une aubaine lorsque vous essayez de git avec git-svn dcommits.

un procédé typique:

1. configurer git repo
2. faire un peu de travail sur les différents fichiers
3. de décider de vérifier certains des travaux, à l'aide de git
4. décider de svn-dcommit
5. obtenir le redouté "ne peut pas s'engager avec un sale indice d'erreur".

La solution (nécessite git 1.5.3+):

git stash; git svn dcommit ; git stash apply

voici un simple script shell sans dépendances qui convertira un ou plusieurs dépôts SVN en Git et les poussera vers GitHub.

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

dans environ 30 lignes de script it: clones en utilisant git SVN, crée un .fichier gitignore de SVN:: ignore les propriétés, pousse dans un dépôt git nu, renomme SVN trunk EN master, convertit SVN tags en git tags, et le pousse vers GitHub tout en préservant les balises.

j'ai beaucoup souffert pour déplacer une douzaine de dépôts SVN de Google Code à GitHub. Ça n'a pas aidé que J'utilise Windows. Ruby avait toutes sortes de casse sur mon ancienne Boîte Debian et le faire fonctionner sur Windows était une blague. D'autres solutions n'ont pas fonctionné avec Cygwin paths. Même une fois que j'ai obtenu quelque chose de travail, je ne pouvais pas comprendre comment obtenir les étiquettes pour apparaître sur GitHub (le secret est --suivi-étiquettes).

À la fin, j' j'ai concocté deux scripts courts et simples, liés ci-dessus, et ça marche très bien. La solution n'a pas besoin d'être plus compliquée que cela!

Pour GitLab les utilisateurs que j'ai mis en place un résumé sur la façon dont je de SVN ici:

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

étapes pour passer de SVN à GitLab

Setup

• SVN est hébergé à svn.domain.com.au .
• SVN est accessible via http (d'autres protocoles devraient fonctionner).
• GitLab est hébergé à git.domain.com.au et:
  • un groupe est créé avec l'espace de noms dev-team .
  • au moins un compte 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 nom dev-team .
• le dossier users.txt contient les détails d'utilisateur pertinents, un utilisateur par ligne, du formulaire username = First Last <address@domain.com.au> , où username est le nom d'utilisateur indiqué dans SVN logs. (Voir le premier lien dans la section Références pour plus de détails, en particulier la réponse de L'utilisateur Casey).

Versions

• de 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 GitLab Web UI et vous verrez toutes les propagations et les fichiers maintenant listés.

Notes

• S'il y a des utilisateurs inconnus, la commande git svn clone s'arrêtera, dans ce cas, la mise à jour users.txt , cd favourite-project et git svn fetch continuera d'où elle s'est arrêtée.
• la norme trunk - tags - branches layout pour SVN repository est nécessaire.
• l'URL SVN donnée à la commande git svn clone s'arrête au niveau immédiatement supérieur à trunk/ , tags/ et branches/ .
• la commande git svn clone produit beaucoup de sortie, y compris quelques avertissements au sommet; j'ai ignoré les Avertissements.

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

https://github.com/onepremise/SGMS

ce script convertira les projets stockés dans SVN avec le format suivant:

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

ce schéma est également populaire et soutenu aussi bien:

/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 la pension complète, utilisez la syntaxe suivante:

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

Im sur une machine windows et fait un petit lot pour transférer un SVN repo avec historique (mais sans branches) à un git repo 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 qui vérifie le rapport SVN avec git et ajoute la nouvelle origine et le pousse... et supprime le dossier à nouveau.

@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 encore besoin des utilisateurs.txt avec vos correspondances d'utilisateur comme

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

utiliser efficacement Git avec Subversion est une introduction douce à git-svn. Pour les dépôts SVN existants, git-svn rend cela très facile. Si vous démarrez un nouveau dépôt, il est beaucoup plus facile de créer un dépôt SVN vide, puis d'importer en utilisant git-svn que d'aller dans la direction opposée. Créer un nouveau dépôt Git puis importer dans SVN peut être fait, mais c'est un peu douloureux, surtout si vous êtes nouveau sur Git et l'espoir de préserver la validation de l'histoire.

téléchargez L'installateur Ruby pour Windows et installez la dernière version avec elle. Ajouter Rubis exécutables sur votre chemin.

• Installer svn2git
• menu Démarrer - > Tous les programmes - > Ruby - > lancer une invite de commande avec Ruby

• tapez" gem install svn2git" et entrez

  Migrer le référentiel Subversion

• ouvrir une invite Ruby command et aller dans le répertoire où les fichiers doivent être migrés ""

  Puis svn2git http://[nom de domaine nom]/svn/ [racine du référentiel]

• Cela peut prendre quelques heures pour migrer le projet Git dépend du projet, de la taille du code.

• cette étape majeure aide à créer la structure de dépôt Git mentionnée ci-dessous.

  SVN (/Project_components) trunk --> git master SVN (/Project_components) branches -- > git branches SVN (/Project_components) tags --> git tags

créer le dépôt à distance et pousser les changements.

GitHub a un importateur. Une fois que vous avez créé le dépôt, vous pouvez importer à partir d'un dépôt existant, via son URL. Il vous demandera vos justificatifs d'identité, s'il y a lieu, et partira de là.

comme il est en cours d'exécution, il trouvera des auteurs, et vous pouvez simplement les map aux utilisateurs sur GitHub.

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

plusieurs réponses renvoient ici à https://github.com/nirvdrum/svn2git , mais pour les grands dépôts cela peut être lent. J'ai essayé https://github.com/svn-all-fast-export/svn2git au lieu de cela qui est un outil avec exactement le même nom mais qui a été utilisé pour migrer KDE de SVN à git.

un peu plus de travail pour le mettre en place, mais quand fait la conversion elle-même pour moi a pris des minutes où l'autre script a passé des heures.

Il existe différentes méthodes pour atteindre cet objectif. J'en ai essayé quelques-uns et j'en ai trouvé un qui fonctionne vraiment avec juste git et svn installés sur Windows OS.

conditions préalables:

1. git on windows (j'ai utilisé celui-ci) https://git-scm.com/
2. svn avec outils de console installés (j'ai utilisé tortoise svn)
3. fichier Dump de votre dépôt SVN. svnadmin dump /path/to/repository > repo_name.svn_dump

étapes pour atteindre le but final (déplacer tout le dépôt historique vers un git, d'abord local git, puis distant)

1. créer un dépôt vide (en utilisant les outils de la console ou tortoiseSVN) dans le répertoire REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER , mettez dumpfile.dump into REPO_NAME_PARENT_FOLDER

2. svnadmin load REPO_NAME_FOLDER < dumpfile.dump attendez cette opération, elle peut être longue

3. cette commande est silencieuse, donc ouvrez la deuxième fenêtre cmd: svnserve -d -R --root REPO_NAME_FOLDER Pourquoi ne pas simplement utiliser le fichier:///...... ? Parce que la prochaine commande échouera avec Unable to open ... to URL: , grâce à la réponse https://stackoverflow.com/a/6300968/4953065

4. créer un nouveau dossier SOURCE_GIT_FOLDER

5. cd SOURCE_GIT_FOLDER
6. git svn clone svn://localhost/ Attendre pour cette opération.

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

vérifions notre dépôt Local:

git log

Si oui-d'accord

donc maintenant vous avez un dépôt git local entièrement fonctionnel avec vos sources et votre ancienne histoire svn. Maintenant, si vous voulez le déplacer vers 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 commande tags pensions n'ont pas de balises.

bonne chance!

Converting svn submodule / folder 'MyModule' en git avec historique sans tags ni branches.

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

pour conserver svn ignore list utilisez les commentaires ci-dessus après l'étape 1