Ho letto il manuale di Git, le domande frequenti, il corso accelerato Git-SVN, ecc. E tutti spiegano questo e quello, ma da nessuna parte puoi trovare una semplice istruzione come:
Repository SVN in: svn://myserver/path/to/svn/repos
Repository Git in: 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
Non mi aspetto che sia così semplice, e non mi aspetto che sia un singolo comando. Ma mi aspetto che non provi a spiegare nulla - solo per dire quali passi prendere dato questo esempio.
Magia:
$ git svn clone http://svn/repo/here/trunk
Git e SVN operano in modo molto diverso. Devi imparare Git, e se vuoi tenere traccia delle modifiche da SVN a monte, devi imparare git-svn
. La pagina man git-svn
ha una buona sezione di esempi:
$ git svn --help
Crea un file utente (ad esempio users.txt
) per mappare gli utenti SVN a Git:
user1 = First Last Name <email@address.com>
user2 = First Last Name <email@address.com>
...
È possibile utilizzare questo one-liner per creare un modello dal repository SVN esistente:
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt
SVN si fermerà se trova un utente SVN mancante non nel file. Ma dopo puoi aggiornare il file e riprendere da dove eri rimasto.
Ora estrai i dati SVN dal repository:
git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path dest_dir-tmp
Questo comando creerà un nuovo repository Git in dest_dir-tmp
e inizierà a estrarre il repository SVN. Nota che il flag "--stdlayout" implica il comune "trunk /, rami /, tag /" layout SVN. Se il tuo layout è diverso, acquisisci familiarità con le opzioni --tags
, --branches
, --trunk
(in generale git svn help
).
Sono consentiti tutti i protocolli comuni: svn://
, http://
, https://
. L'URL deve essere indirizzato al repository di base, ad esempio http://svn.mycompany.com/myrepo/repository . Deve non include /trunk
, /tag
o /branches
.
Nota che dopo aver eseguito questo comando sembra molto spesso che l'operazione sia "sospesa/bloccata", ed è abbastanza normale che possa rimanere bloccata per un lungo periodo di tempo dopo l'inizializzazione del nuovo repository. Alla fine vedrai i messaggi di log che indicano che sta migrando.
Si noti inoltre che se si omette il flag --no-metadata
, Git aggiungerà le informazioni sulla revisione SVN corrispondente al messaggio di commit (ad esempio git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID>
)
Se non si trova un nome utente, aggiornare il file users.txt
quindi:
cd dest_dir-tmp
git svn fetch
Potrebbe essere necessario ripetere l'ultimo comando più volte, se si dispone di un progetto di grandi dimensioni, fino a quando tutti i commit di Subversion non sono stati recuperati:
git svn fetch
Una volta completato, Git eseguirà il checkout di SVN trunk
in una nuova filiale. Tutti gli altri rami sono configurati come telecomandi. È possibile visualizzare gli altri rami SVN con:
git branch -r
Se si desidera mantenere altre filiali remote nel proprio repository, si desidera creare manualmente un ramo locale per ciascun repository. (Salta trunk/master.) Se non lo fai, i rami non verranno clonati nel passaggio finale.
git checkout -b local_branch remote_branch
# It's OK if local_branch and remote_branch are the same name
I tag vengono importati come rami. Devi creare un ramo locale, creare un tag ed eliminare il ramo per averli come tag in Git. Per farlo con il tag "v1":
git checkout -b tag_v1 remotes/tags/v1
git checkout master
git tag v1 tag_v1
git branch -D tag_v1
Clona il tuo repository GIT-SVN in un repository Git pulito:
git clone dest_dir-tmp dest_dir
rm -rf dest_dir-tmp
cd dest_dir
I rami locali creati in precedenza dai rami remoti saranno stati copiati come diramazioni remote nel nuovo repository clonato. (Salta trunk/master.) Per ogni ramo che si desidera mantenere:
git checkout -b local_branch Origin/remote_branch
Infine, rimuovi il telecomando dal tuo repository Git pulito che punta al repository temporaneo ora eliminato:
git remote rm Origin
Migrazione pulita del repository di Subversion in un repository Git . Per prima cosa devi creare un file che mappi i nomi degli autori di commit di Subversion ai commiters Git, ad esempio ~/authors.txt
:
jmaddox = Jon Maddox <jon@gmail.com>
bigpappa = Brian Biggs <bigpappa@gmail.com>
Quindi puoi scaricare i dati di Subversion in un repository Git:
mkdir repo && cd repo
git svn init http://Subversion/repo --no-metadata
git config svn.authorsfile ~/authors.txt
git svn fetch
Se sei su un Mac, puoi ottenere git-svn
da MacPorts installando git-core +svn
.
Se il repository di Subversion si trova sulla stessa macchina del repository git desiderato, puoi usare questa sintassi per il passo init, altrimenti tutti uguali:
git svn init file:///home/user/repoName --no-metadata
Ho usato lo script svn2git e funziona come un incantesimo.
Suggerisco di familiarizzare con Git prima di provare a usare git-svn costantemente, cioè mantenendo SVN come repository centralizzato e usando Git localmente.
Tuttavia, per una semplice migrazione con tutta la cronologia, ecco i pochi semplici passaggi:
Inizializza il repository locale:
mkdir project
cd project
git svn init http://svn.url
Indica fino a che punto vuoi iniziare a importare le revisioni:
git svn fetch -r42
(o semplicemente "git svn fetch" per tutti i revs)
In realtà, recupera tutto da allora:
git svn rebase
Puoi controllare il risultato dell'importazione con Gitk. Non sono sicuro che funzioni su Windows, funziona su OSX e Linux:
gitk
Dopo aver clonato localmente il repository SVN, è possibile inviarlo a un repository Git centralizzato per una collaborazione più semplice.
Prima crea il tuo repository remoto vuoto (magari su GitHub ?):
git remote add Origin git@github.com:user/project-name.git
Quindi, opzionalmente, sincronizza il tuo ramo principale in modo che l'operazione di estrazione fonderà automaticamente il master remoto con il tuo master locale, quando entrambi contengono nuove cose:
git config branch.master.remote Origin
git config branch.master.merge refs/heads/master
Successivamente, potresti essere interessato a provare il mio strumento git_remote_branch
, che aiuta a gestire i rami remoti:
Primo post esplicativo: " Git remote branches "
Follow-up per la versione più recente: " È ora di collaborare con git_remote_branch "
Esiste una nuova soluzione per una migrazione fluida da Subversion a Git (o per l'utilizzo simultaneo di entrambi): SubGit .
Sto lavorando a questo progetto da solo. Usiamo SubGit nei nostri repository - alcuni dei miei compagni di squadra usano Git e alcuni Subversion e finora funziona molto bene.
Per eseguire la migrazione da Subversion a Git con SubGit è necessario eseguire:
$ subgit install svn_repos
...
TRANSLATION SUCCESSFUL
Dopodiché avrai il repository Git in svn_repos/.git e potresti clonarlo, o semplicemente continuare ad usare Subversion e questo nuovo repository Git insieme: SubGit farà in modo che entrambi siano sempre sincronizzati.
Nel caso in cui il repository Subversion contenga più progetti, verranno creati più repository Git nella directory svn_repos/git. Per personalizzare la traduzione prima di eseguirla, procedi come segue:
$ subgit configure svn_repos
$ edit svn_repos/conf/subgit.conf (change mapping, add authors mapping, etc)
$ subgit install svn_repos
Con SubGit puoi migrare a Git puro (non a git-svn) e iniziare a usarlo mentre stai ancora mantenendo Subversion finché ne hai bisogno (per gli strumenti di compilazione già configurati, per esempio).
Spero che questo ti aiuti!
Vedi la pagina ufficiale di git-svn . In particolare, guarda sotto "Esempi di base":
Monitoraggio e contributo a un intero progetto gestito da Subversion (completo di trunk, tag e rami):
# Clone a repo (like git clone):
git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
Pro Git 8.2 lo spiega: http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git
subgit import --svn-url url://svn.serv/Bla/Bla directory/path/Local.git.Repo
È tutto.
+ Per aggiornare da SVN, un repository Git creato dal primo comando.
subgit import directory/path/Local.git.Repo
Ho usato un modo per migrare a Git all'istante per un enorme repository.
Certo che hai bisogno di un po 'di preparazione.
Ma potresti non interrompere affatto il processo di sviluppo.
Ecco la mia strada.
La mia soluzione sembra:
La migrazione richiede molto tempo per un grande repository SVN.
Ma l'aggiornamento della migrazione completata è di pochi secondi.
Ovviamente sto usando SubGit , mamma. git-svn mi fa Blue Screen of Death . Solo costantemente E git-svn mi annoia con Git's " filename too long " errore fatale.
STEPS
2. Prepara migrare e aggiornare i comandi.
Diciamo che lo facciamo per Windows (è banale portarlo su Linux).
Nell'installazione di un SubGit bin directory (subgit-2.X.X\bin), creare due file .bat.
Contenuto di un file/comando per la migrazione:
start subgit import --svn-url url://svn.serv/Bla/Bla directory/path/Local.git.Repo
Il comando "start" è facoltativo qui (Windows). Permetterà di vedere gli errori all'avvio e ha lasciato una Shell aperta dopo il completamento del SubGit.
Puoi aggiungere qui parametri aggiuntivi simili a git-svn . Sto usando solo - dominio predefinito myCompanyDomain.com per correggere il dominio dell'indirizzo email degli autori SVN.
Ho la struttura del repository SVN standard (trunk/branches/tags) e non abbiamo avuto problemi con "author mapping". Quindi non sto più facendo niente.
(Se vuoi migrare tag come rami o il tuo SVN ha più filiali/tag puoi prendere in considerazione l'uso del più dettagliato SubGit approach )
Suggerimento 1 : usa --minimal-revision YourSvnRevNumber per vedere velocemente come vanno le cose (una sorta di debugging). È particolarmente utile vedere i nomi degli autori o le e-mail risolti.
O per limitare la profondità della cronologia delle migrazioni.
Suggerimento 2 : la migrazione potrebbe essere interrotta (Ctrl + C) e ripristinato eseguendo il prossimo comando/file di aggiornamento.
Non consiglio di farlo per grandi repository. Ho ricevuto "Eccezione Java + memoria esaurita".
Suggerimento 3 : meglio creare una copia del repository di risultati nudi.
Contenuto di un file/comando per l'aggiornamento:
start subgit import directory/path/Local.git.Repo
Puoi eseguirlo tutte le volte che vuoi ottenere i commit dell'ultima squadra nel tuo repository Git.
Attenzione! Non toccare il tuo repository (creazione di rami per esempio).
Avrai il prossimo errore fatale:
Errore irreversibile: non sono sincronizzati e non possono essere sincronizzati ... Tradurre le revisioni Subversion su Git si impegna ...
3. Esegui il primo comando/file. Ci vorrà un tempo moooolto per un grande repository. 30 ore per il mio umile repository.
È tutto.
Puoi aggiornare il tuo repository Git da SVN in qualsiasi momento, eseguendo il secondo file/comando. E prima di passare dal tuo team di sviluppo a Git.
Ci vorranno solo pochi secondi.
C'è un altro compito utile.
Invia il tuo repository Git locale a un repository Git remoto
È il tuo caso? Procediamo.
Correre:
$ git remote add Origin url://your/repo.git
Di default il tuo Git non può inviare grossi pezzi. fatale: il capo remoto riattaccato in modo imprevisto
Corriamo per questo:
git config --global http.postBuffer 1073741824
524288000 - 500 MB 1073741824 - 1 GB, ecc.
Correggi il tuo locale problemi con i certificati . Se il tuo git-server usa un certificato rotto.
Ho disabilitato certificates .
Anche il tuo server Git potrebbe avere un limiti di quantità della richiesta che devono essere corretti .
Esegui con un Git locale:
git Push Origin --mirror
( git Push Origin '*: *' per le vecchie versioni Git)
Se ottieni quanto segue: errore: impossibile generare git: Nessun file o directory ... Per me la piena ricreazione del mio repository risolve questo errore ( 30 ore). Puoi provare i prossimi comandi
git Push Origin --all
git Push Origin --tags
Oppure prova a reinstallare Git ( inutile per me ). Oppure puoi creare rami da tutti i tag e inviarli. O, o, o ...
Per casi complicati, reposurgeon di Eric S. Raymond è lo strumento di scelta. Oltre a SVN, supporta molti altri sistemi di controllo versioni tramite il formato fast-export
e anche CVS . L'autore riporta conversioni riuscite di repository antichi come Emacs e FreeBSD .
Apparentemente lo strumento punta alla conversione quasi perfetta (come la conversione delle proprietà svn:ignore
di SVN in file .gitignore
) anche per i layout dei repository difficili con una lunga storia. Per molti casi, altri strumenti potrebbero essere più facili da usare.
Prima di approfondire la documentazione della riga di comando reposurgeon
, assicurati di leggere l'eccellente Guida alla migrazione DVCS che segue passo dopo passo il processo di conversione.
Questa guida sul sito di atlassian è una delle migliori che ho trovato:
https://www.atlassian.com/git/migration
Questo strumento - https://bitbucket.org/atlassian/svn-migration-scripts - è anche molto utile per generare il tuo authors.txt tra le altre cose.
Devi installare
git
git-svn
Copiato da questo link http://john.albin.net/git/convert-Subversion-to-git .
1. Recupera una lista di tutti i committer Subversion
Subversion elenca semplicemente il nome utente per ogni commit. I commit di Git hanno dati molto più ricchi, ma nel modo più semplice, l'autore del commit deve avere un nome e un indirizzo email elencati. Per impostazione predefinita, lo strumento git-svn elencherà solo il nome utente SVN nei campi dell'autore e dell'email. Ma con un po 'di lavoro, puoi creare un elenco di tutti gli utenti SVN e qual è il loro nome e le email Git corrispondenti. Questo elenco può essere usato da git-svn per trasformare semplici nomi utente svn in veri e propri committer Git.
Dalla radice del checkout di Subversion locale, esegui questo comando:
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
Ciò catturerà tutti i messaggi di log, eliminerà i nomi utente, eliminerà eventuali nomi utente duplicati, classificherà i nomi utente e li inserirà in un file "authors-transform.txt". Ora modifica ogni riga nel file. Ad esempio, convertire:
jwilkins = jwilkins <jwilkins>
in questo:
jwilkins = John Albin Wilkins <johnalbin@example.com>
2. Clona il repository Subversion usando git-svn
git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp
Questo farà la trasformazione git-svn standard (usando il file authors-transform.txt creato nel passaggio 1) e posizionerai il repository git nella cartella "~/temp" all'interno della tua home directory.
3. Converti svn: ignora le proprietà in .gitignore
Se il tuo repository SVN stava usando svn: ignora le proprietà, puoi facilmente convertirlo in un file .gitignore usando:
cd ~/temp
git svn show-ignore > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'
4. Push repository in un repository git nudo
Per prima cosa, crea un repository nudo e fai in modo che il suo ramo predefinito corrisponda al nome del ramo "tronco" di svn.
git init --bare ~/new-bare.git
cd ~/new-bare.git
git symbolic-ref HEAD refs/heads/trunk
Quindi, spingere il repository temporaneo nel nuovo repository nudo.
cd ~/temp
git remote add bare ~/new-bare.git
git config remote.bare.Push 'refs/remotes/*:refs/heads/*'
git Push bare
Ora puoi tranquillamente eliminare il repository ~/temp.
5. Rinomina il ramo "tronco" in "master"
Il tuo ramo di sviluppo principale sarà denominato "trunk" che corrisponde al nome che era in Subversion. Dovrai rinominarlo nel ramo "master" standard di Git usando:
cd ~/new-bare.git
git branch -m trunk master
6. Pulizia di rami e tag
git-svn rende tutti i tag Subversions in rami molto brevi in Git del modulo "tags/name". Ti consigliamo di convertire tutti quei rami in veri tag Git usando:
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
Questo passaggio richiederà un po 'di digitazione. :-) Ma non preoccuparti; la tua shell unix fornirà un> prompt secondario per il comando extra-long che inizia con git for-each-ref.
Una risposta piuttosto estesa usando solo git, SVN e bash. Include passaggi per repository SVN che non utilizzano il layout convenzionale con un layout di directory trunk/branches/tags (SVN non fa assolutamente nulla per imporre questo tipo di layout).
Innanzitutto utilizza questo script bash per eseguire la scansione del repository SVN per le diverse persone che hanno contribuito e per generare un modello per un file di mapping:
#!/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
Usalo per creare un file authors
dove mappi i nomi utente svn ai nomi utente e ai messaggi di posta elettronica impostati dai tuoi sviluppatori usando git config
properties user.name
e user.email
(nota che per un servizio come GitHub è sufficiente avere un'e-mail corrispondente).
Quindi avere git svn
clonare il repository svn in un repository git, indicando la mappatura:
git svn clone --authors-file=authors --stdlayout svn://example.org/Folder/projectroot
Questo può richiedere incredibilmente molto tempo, dal momento che git svn controllerà individualmente ogni revisione per ogni tag o ramo esistente. (nota che i tag in SVN sono solo in realtà rami, quindi finiscono come tali in Git). Puoi accelerare rimuovendo vecchi tag e rami in SVN che non ti servono.
L'esecuzione di questo su un server nella stessa rete o sullo stesso server può anche velocizzarlo. Inoltre, se per qualche motivo questo processo viene interrotto si può riprenderlo usando
git svn rebase --continue
In molti casi hai finito qui. Ma se il repository SVN ha un layout non convenzionale in cui si ha semplicemente una directory in SVN che si desidera inserire in un ramo git, è possibile eseguire alcuni passaggi aggiuntivi.
La cosa più semplice è semplicemente creare un nuovo repository SVN sul server che segua le convenzioni e usi svn copy
per mettere la directory nel bagagliaio o in un ramo. Questo potrebbe essere l'unico modo se la tua directory è nella root del repository, quando ho provato questo git svn
si è semplicemente rifiutata di fare un checkout.
Puoi anche farlo usando git. Per git svn clone
usa semplicemente la directory che vuoi inserire in un ramo git.
Dopo la corsa
git branch --set-upstream master git-svn
git svn rebase
Si noti che questo richiede Git 1.7 o superiore.
GitHub ora ha una funzione per importare da un repository SVN . Non l'ho mai provato, però.
Ho pubblicato una guida passo dopo passo ( qui ) per convertire svn in git inclusa la conversione di tag svn in tag git e rami svn nei rami git.
Versione breve:
1) clone svn da un numero di revisione specifico. (il numero di revisione deve essere il più vecchio che si desidera migrare)
git svn clone --username=yourSvnUsername -T trunk_subdir -t tags_subdir -b branches_subdir -r aRevisionNumber svn_url gitreponame
2) preleva dati svn. Questo passo è quello che impiega più tempo.
cd gitreponame
git svn fetch
ripeti git svn fetch finché non termina senza errori
3) aggiornare il ramo principale
git svn rebase
4) Creare rami locali dai rami svn copiando i riferimenti
cp .git/refs/remotes/Origin/* .git/refs/heads/
5) convertire tag svn in tag 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) Metti un repository in un posto migliore come github
git remotes add newrepo git@github.com:aUser/aProjectName.git
git Push newrepo refs/heads/*
git Push --tags newrepo
Se vuoi maggiori dettagli, leggi il mio post o chiedimi.
Possiamo usare i comandi git svn clone
come di seguito.
svn log -q <SVN_URL> | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors.txt
Il comando sopra creerà il file degli autori da commit SVN.
svn log --stop-on-copy <SVN_URL>
Il comando sopra ti darà il primo numero di revisione quando il tuo progetto SVN è stato creato.
git svn clone -r<SVN_REV_NO>:HEAD --no-minimize-url --stdlayout --no-metadata --authors-file authors.txt <SVN_URL>
Il comando sopra creerà il repository Git in locale.
Il problema è che non converte rami e tag in Push. Dovrai farli manualmente. Per esempio sotto per rami:
$ 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
$
Per i tag:
$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
$
Ora Push master, branch e tag nel repository git remoto.
$ 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 utility rimuove gli sforzi manuali con rami e tag.
Installalo usando il comando Sudo gem install svn2git
. Dopo di che corri sotto il comando.
$ svn2git <SVN_URL> --authors authors.txt --revision <SVN_REV_NO>
Ora puoi elencare i rami, i tag e spingerli facilmente.
$ 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
Immagina di avere 20 rami e tag, ovviamente svn2git ti farà risparmiare un sacco di tempo ed è per questo che mi piace meglio dei comandi nativi. È un bel wrapper attorno al comando git svn clone
nativo.
Per un esempio completo, fai riferimento al mio post di blog .
TortoiseGit fa questo. vedi questo post sul blog: http://jimmykeen.net/articles/03-nov-2012/how-migrate-from-svn-to-git-windows-using-tortoise-clients
Sì, so che rispondere con i link non è splendido ma è una soluzione, eh?
Per GitLab users Ho creato un Gist su come sono migrato da SVN qui:
https://Gist.github.com/leftclickben/322b7a3042cbe97ed2af
svn.domain.com.au
.http
(altri protocolli dovrebbero funzionare).git.domain.com.au
e: dev-team
.ssh git@git.domain.com.au
).favourite-project
viene creato nello spazio dei nomi dev-team
.users.txt
contiene i dettagli utente rilevanti, un utente per riga, del modulo username = First Last <address@domain.com.au>
, dove username
è il nome utente fornito nei log SVN. (Vedi il primo collegamento nella sezione Riferimenti per i dettagli, in particolare la risposta dell'utente Casey).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
Questo è tutto! Ricarica la pagina del progetto nell'interfaccia utente web GitLab e vedrai tutti i commit e i file ora elencati.
git svn clone
si fermerà, nel qual caso l'aggiornamento users.txt
, cd favourite-project
e git svn fetch
continueranno da dove si è fermato.trunk
name __-tags
name __-branches
layout per il repository SVN.git svn clone
si arresta al livello immediatamente superiore trunk/
, tags/
e branches/
.git svn clone
produce un sacco di output, inclusi alcuni avvisi in alto; Ho ignorato gli avvertimenti.Se stai usando SourceTree puoi farlo direttamente dall'app. Vai a File -> Nuovo/Clona quindi fai quanto segue:
Apri il repository in SourceTree e vedrai che anche i tuoi messaggi di commit sono stati migrati.
Ora vai nel repository -> Impostazioni del repository e aggiungi i nuovi dettagli del repository remoto. Elimina il telecomando SVN se lo desideri (l'ho fatto tramite l'opzione "Modifica file di configurazione").
Spingi il codice sul nuovo repository remoto quando sei pronto e codice liberamente.
Consiglio vivamente questa una breve serie di screencast ho appena scoperto. L'autore ti guida attraverso le operazioni di base e mostra alcuni usi più avanzati.
Ecco un semplice script di shell senza dipendenze che convertirà uno o più repository SVN in git e li invierà a GitHub.
https://Gist.github.com/NathanSweet/7327535
In circa 30 righe di script: cloni che utilizzano git SVN, crea un file .gitignore da SVN :: ignora le proprietà, spinge in un repository git nudo, rinomina il trunk SVN in master, converte i tag SVN in tag git e lo invia a GitHub pur preservando i tag.
Ho sofferto molto per spostare una dozzina di repository SVN da Google Code a GitHub. Non ha aiutato che ho usato Windows. Ruby era tutto un po 'rotto sulla mia vecchia scatola Debian e farla funzionare su Windows era uno scherzo. Altre soluzioni non funzionavano con i percorsi Cygwin. Anche una volta che ho ottenuto qualcosa funzionante, non sono riuscito a capire come ottenere i tag su GitHub (il segreto è --follow-tags).
Alla fine ho messo insieme due script brevi e semplici, collegati sopra, e funziona alla grande. La soluzione non deve essere più complicata di così!
A parte questo, il comando git-stash è una manna dal cielo quando si prova a git con git-svn dcommits.
Un processo tipico:
svn-dcommit
La soluzione (richiede git 1.5.3+):
git stash; git svn dcommit ; git stash apply
Sono su una macchina Windows e ho creato un piccolo batch per trasferire un repository SVN con cronologia (ma senza rami) a un repository GIT chiamando semplicemente
transfer.bat http://svn.my.address/svn/myrepo/trunk https://git.my.address/orga/myrepo
Forse qualcuno può usarlo. Crea una cartella TMP controlla il repository SVN lì con git e aggiunge la nuova Origin e la spinge ... e cancella di nuovo la cartella.
@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%
Hai ancora bisogno del file users.txt con i tuoi profili utente come
User1 = User One <u.1@xxx.com>
Volevo solo aggiungere il mio contributo alla community Git. Ho scritto un semplice script bash che automatizza l'importazione completa. A differenza di altri strumenti di migrazione, questo strumento si basa su git nativo invece di jGit. Questo strumento supporta anche repository con una cronologia delle revisioni di grandi dimensioni o blob di grandi dimensioni. È disponibile tramite github:
https://github.com/onepremise/SGMS
Questo script convertirà i progetti memorizzati in SVN con il seguente formato:
/trunk
/Project1
/Project2
/branches
/Project1
/Project2
/tags
/Project1
/Project2
Anche questo schema è popolare e supportato:
/Project1
/trunk
/branches
/tags
/Project2
/trunk
/branches
/tags
Ogni progetto verrà sincronizzato per nome del progetto:
Ex: ./migration https://svnurl.com/basepath project1
Se si desidera convertire il repository completo, utilizzare la seguente sintassi:
Ex: ./migration https://svnurl.com/basepath .
Esistono diversi metodi per raggiungere questo obiettivo. Ne ho provati alcuni e ne ho trovato uno veramente funzionante con solo git e svn installati sul sistema operativo Windows.
Prerequisiti:
svnadmin dump /path/to/repository > repo_name.svn_dump
Passi per raggiungere l'obiettivo finale (spostare tutto il repository con la cronologia in un git, prima git locale, quindi remoto)
Crea un repository vuoto (usando gli strumenti della console o tortoiseSVN) nella directory REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER
, metti dumpfile.dump in REPO_NAME_PARENT_FOLDER
svnadmin load REPO_NAME_FOLDER < dumpfile.dump
Attendi questa operazione, potrebbe essere lunga
Questo comando è silenzioso, quindi apri la seconda finestra cmd: svnserve -d -R --root REPO_NAME_FOLDER
Perché non usare solo file: /// ......? Perché il prossimo comando fallirà con Unable to open ... to URL:
, grazie alla risposta https://stackoverflow.com/a/6300968/4953065
Crea una nuova cartella SOURCE_GIT_FOLDER
cd SOURCE_GIT_FOLDER
Finalmente, cosa abbiamo?
Consente di controllare il nostro repository locale:
git log
Vedi i tuoi precedenti commit? Se sì, va bene
Quindi ora hai un repository git locale completamente funzionante con le tue fonti e la vecchia storia di svn. Ora, se vuoi spostarlo su un server, usa i seguenti comandi:
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
Nel mio caso, non ho bisogno di tag comando perché il mio repository non ha tag.
In bocca al lupo!
GitHub ha un importatore. Una volta creato il repository, puoi importarlo da un repository esistente, tramite il suo URL. Richiederà le tue credenziali se applicabile e andrà da lì.
Mentre è in esecuzione, troverà autori e potrai semplicemente associarli agli utenti su GitHub.
L'ho usato per alcuni repository ora, ed è abbastanza preciso e molto più veloce! Ci sono voluti 10 minuti per un repository con ~ 4000 commit, e dopo che ci sono voluti quattro giorni il mio amico!
Utilizzare in modo efficace Git con Subversionè una delicata introduzione a git-svn. Per i repository SVN esistenti, git-svn rende questo estremamente semplice. Se stai iniziando un nuovo repository, è molto più semplice creare un repository SVN vuoto e poi importarlo usando git-svn piuttosto che andare nella direzione opposta. Creare un nuovo repository Git e importarlo in SVN può essere fatto, ma è un po 'doloroso, specialmente se sei nuovo a Git e speri di preservare la cronologia dei commit.
Diverse risposte qui si riferiscono a https://github.com/nirvdrum/svn2git , ma per i repository di grandi dimensioni questo può essere lento. Ho provato usando https://github.com/svn-all-fast-export/svn2git invece che è uno strumento con esattamente lo stesso nome ma è stato usato per migrare KDE da SVN a Git.
Un po 'di lavoro in più per configurarlo, ma una volta terminata la conversione, sono stati necessari minuti in cui l'altro script ha impiegato ore.
Scarica il programma di installazione di Ruby per Windows e installa con esso la versione più recente. Aggiungi gli eseguibili Ruby al tuo percorso.
Quindi digitare "gem install svn2git" e immettere
Migrate repository Subversion
Apri un comando Ruby Prompt e vai alla directory in cui i file devono essere migrati
Quindi svn2git http: // [dominio nome]/svn/[root repository]
Potrebbero essere necessarie alcune ore per migrare il progetto in Git, a seconda della dimensione del codice del progetto.
Questo passaggio importante aiuta a creare la struttura del repository Git come indicato di seguito.
Trunk SVN (/ Project_components) -> Git master SVN (/ Project_components) rami -> Git branches SVN (/ Project_components) tag -> Git tags
Creare il repository remoto e premere le modifiche.
Ho usato il seguente script per leggere un file di testo che ha un elenco di tutti i miei repository SVN e convertirli in Git, e successivamente usare git clone --bare
per convertirli in un repository Git spoglio:
#!/bin/bash
file="list.txt"
while IFS= read -r repo_name
do
printf '%s\n' "$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 ha il formato:
repo1_name
repo2_name
E users.txt ha il formato:
(no author) = Prince Rogers <prince.rogers.nelson@payesley.park.org>
www-data è l'utente del server Web Apache e l'autorizzazione è necessaria per trasferire le modifiche su HTTP.
Conversione del sottomodulo/cartella svn 'MyModule' in git con la cronologia senza tag né rami.
Per mantenere l'elenco ignora ignorare i commenti sopra dopo il punto 1