version-control migrate - Come posso migrare un repository SVN con la cronologia in un nuovo repository Git?




switch bitbucket (25)

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 è possibile 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.


Answers

Ho usato lo script svn2git e funziona come un incantesimo! https://github.com/nirvdrum/svn2git


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

Consiglio vivamente questa breve serie di screencast che ho appena scoperto. L'autore ti guida attraverso le operazioni di base e mostra alcuni usi più avanzati.



SubGit (vs Blue Screen of Death)

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:

  • Migrazione di SVN in un repository Git
  • Aggiorna il repository Git poco prima che il team passi a .

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 rende Blue Screen of Death . Solo costantemente E git-svn mi annoia con l'errore fatale di " nome file troppo lungo " di Git.

PASSI

1. Scarica SubGit

2. Preparare la migrazione e l'aggiornamento dei comandi.

Diciamo che lo facciamo per Windows (è banale portarlo su Linux).
Nella directory bin di installazione di SubGit (subgit-2.XX \ 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 SubGit . 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 dell'approccio SubGit più dettagliato)

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 può essere interrotta ( Ctrl + C ) e ripristinata 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.

Avvertimento! Non toccare il tuo repository nudo (creazione di rami per esempio).
Prenderai 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
È possibile aggiornare il 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.

  1. Configura i tuoi telecomandi

Correre:

$ git remote add origin url://your/repo.git
  1. Preparati all'invio iniziale dell'enorme repository Git locale a un repository remoto

Di default il tuo Git non può inviare grossi pezzi. fatale: il telecomando si è bloccato inaspettatamente

Corriamo per questo:

git config --global http.postBuffer 1073741824

524288000 - 500 MB 1073741824 - 1 GB, ecc.

Risolve i problemi del certificato locale. Se il tuo git-server usa un certificato rotto.

Ho dei certificates disabilitati.

Anche il tuo server Git può avere una limitazione dell'importo della richiesta che deve essere corretta .

  1. Spingi tutta la migrazione al repository Git remoto del team.

Esegui con un Git locale:

git push origin --mirror

( git push origin '*: *' per le vecchie versioni di Git)

Se si ottiene 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

O prova a reinstallare Git ( inutile per me ). Oppure puoi creare rami da tutti i tag e spingerli. O, o, o ...



Possiamo usare i comandi git svn clone come sotto.

  • 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 da spingere. 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 premi master, rami 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
$

utility svn2git

https://github.com/nirvdrum/svn2git utility https://github.com/nirvdrum/svn2git 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 nativo git svn clone .

Per un esempio completo, fai riferimento al mio post di blog .


Diverse risposte qui si riferiscono a https://github.com/nirvdrum/svn2git , ma per i repository di grandi dimensioni questo può essere lento. Ho provato a utilizzare https://github.com/svn-all-fast-export/svn2git che è uno strumento con lo stesso nome ma che è stato utilizzato per migrare KDE da SVN a Git.

Un po 'di lavoro in più per configurarlo, ma una volta terminata la conversione stessa sono stati necessari minuti in cui l'altro script ha impiegato ore.


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 origine 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 mapping utente come

User1 = User One <[email protected]>

Esiste una nuova soluzione per una migrazione fluida da Subversion a Git (o per l'utilizzo simultaneo di entrambi): SubGit ( http://subgit.com/ ).

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 mantenuti 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 http://subgit.com/ è possibile migrare a Git puro (non a git-svn) e iniziare a usarlo mantenendo comunque Subversion finché ne hai bisogno (per gli strumenti di compilazione già configurati, ad esempio).

Spero che questo ti aiuti!


Crea un file utente (es. users.txt ) per mappare gli utenti SVN a Git:

user1 = First Last Name <[email protected]>
user2 = First Last Name <[email protected]>
...

Puoi usare questo one-liner per creare un template dal tuo 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 /, branches /, tags /" layout SVN. Se il tuo layout è diverso, acquisisci familiarità con le --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 . Questo non deve includere /trunk , /tag o /branches .

Nota che dopo aver eseguito questo comando sembra molto spesso che l'operazione sia "sospesa / libera" 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 (es. Git git-svn-id: svn://svn.mycompany.com/myrepo/<branchname/trunk>@<RevisionNumber> <Repository UUID> )

Se un nome utente non viene trovato, aggiorna 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 del trunk SVN 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

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 <[email protected]>

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 che hai creato nel passaggio 1) e collochi 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 su 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 "trunk" 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". Dovrai 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.


Se stai usando SourceTree puoi farlo direttamente dall'app. Vai a File -> Nuovo / Clona quindi fai quanto segue:

  1. Immettere l'URL SVN remoto come "Percorso / URL di origine".
  2. Inserisci le tue credenziali quando richiesto.
  3. Immettere il percorso della cartella locale come "Percorso di destinazione".
  4. Dagli un nome.
  5. Nelle opzioni avanzate selezionare "Git" dal menu a tendina in "Crea repository locale di tipo".
  6. Opzionalmente è possibile specificare una revisione da cui clonare.
  7. Hit Clone.

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.


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 di git-svn ha una buona sezione di esempi:

$ git svn --help

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:

  1. git su windows (ho usato questo) https://git-scm.com/
  2. svn con gli strumenti della console installati (ho usato tnnoise svn)
  3. Scarica il file del tuo repository SVN. svnadmin dump /path/to/repository > repo_name.svn_dump

Passi per raggiungere l'obiettivo finale (spostare tutti i repository con la cronologia in un git, in primo luogo git locale, quindi remoto)

  1. Crea un repository vuoto (utilizzando gli strumenti della console o tortoiseSVN) nella directory REPO_NAME_FOLDER cd REPO_NAME_PARENT_FOLDER, metti dumpfile.dump in REPO_NAME_PARENT_FOLDER

  2. svnadmin load REPO_NAME_FOLDER < dumpfile.dump Aspetta questa operazione, potrebbe essere lunga

  3. Questo comando è silenzioso, quindi apri la seconda finestra di cmd: svnserve -d -R --root REPO_NAME_FOLDERPerché non usare solo file: /// ......? Perché il prossimo comando fallirà Unable to open ... to URL:, grazie alla risposta https://.com/a/6300968/4953065

  4. Crea una nuova cartella SOURCE_GIT_FOLDER

  5. cd SOURCE_GIT_FOLDER
  6. git svn clone svn: // localhost / Attendi questa operazione.

Finalmente, cosa abbiamo?

Consente di controllare il nostro repository locale:

git log

Vedi i tuoi precedenti commit? Se sì, va bene

Così 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!



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 <[email protected]>";
done

Usalo per creare un file di authors cui mappi nomi utente svn a nomi utente e email come impostati dai tuoi sviluppatori utilizzando le proprietà git config user.name e user.email (nota che per un servizio come GitHub è sufficiente avere solo un'email corrispondente).

Quindi git svn clona 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 a lungo, dal momento che git svn controllerà individualmente ogni revisione per ogni tag o ramo esistente. (nota che i tag in SVN sono solo rami veri, 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, puoi 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 la svn copy per mettere la directory nel bagagliaio o in un ramo. Questo potrebbe essere l'unico modo se la tua directory è tutta nella root del repository, quando ho provato questo git svn semplicemente rifiutato di fare un checkout.

Puoi farlo anche 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.


Scarica il programma di installazione di Ruby per Windows e installa con esso la versione più recente. Aggiungi gli eseguibili Ruby al tuo percorso.

  • Installa svn2git
  • Menu Start -> Tutti i programmi -> Ruby -> Avvia un prompt dei comandi con Ruby
  • Quindi digita "gem install svn2git" e inserisci

    Migrare il repository Subversion

  • Aprire un prompt dei comandi Ruby e andare alla directory in cui i file devono essere migrati

    Quindi svn2git http: // [ nome dominio ] / 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 inviare le modifiche.


Usare in modo efficace Git con Subversion è una semplice introduzione a git-svn. Per i repository SVN esistenti, git-svn rende questo super facile. Se stai iniziando un nuovo repository, è molto più semplice creare un repository SVN vuoto e quindi 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.


A parte questo, il comando git-stash è una manna dal cielo quando si prova a git con git-svn dcommits.

Un processo tipico:

  1. configurare il repository git
  2. fare del lavoro su diversi file
  3. decidere di controllare parte del lavoro, usando git
  4. decidere di svn-dcommit
  5. ottenere il temuto errore "impossibile eseguire il commit con un indice sporco".

La soluzione (richiede git 1.5.3+):

git stash; git svn dcommit ; git stash apply

GitHub ha un importatore. Una volta creato il repository, è possibile eseguire l'importazione da un repository esistente, tramite il relativo 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!


reposurgeon

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 di fast-export e anche CVS . L'autore riporta conversioni di successo di repository antichi come Emacs e FreeBSD .

Apparentemente lo strumento punta a una conversione quasi perfetta (come la conversione di SVN SVN svn:ignore proprietà 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 reposurgeon comando del reposurgeon , assicurati di leggere l'eccellente guida alla migrazione DVCS che segue passo dopo passo il processo di conversione.


Per gli utenti GitLab ho messo un sommario su come sono migrato da SVN qui:

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

Passaggi per migrare da SVN a GitLab

Impostare

  • SVN è ospitato su svn.domain.com.au.
  • SVN è accessibile tramite http(altri protocolli dovrebbero funzionare).
  • GitLab è ospitato su git.domain.com.aue:
    • Un gruppo viene creato con lo spazio dei nomi dev-team.
    • Almeno un account utente viene creato, aggiunto al gruppo e ha una chiave SSH per l'account utilizzato per la migrazione (test utilizzando ssh [email protected]).
    • Il progetto favourite-projectè stato creato nel dev-teamnamespace.
  • Il file users.txtcontiene i dettagli utente rilevanti, un utente per riga, del modulo username = First Last <[email protected]>, dove usernameè indicato il nome utente nei log SVN. (Vedi il primo collegamento nella sezione Riferimenti per i dettagli, in particolare la risposta dell'utente Casey).

versioni

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

comandi

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 [email protected]: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.

Gli appunti

  • Se ci sono gli utenti sconosciuti, il git svn clonecomando si ferma, in tal caso, l'aggiornamento users.txt, cd favourite-projecte git svn fetchcontinuerà dal punto in cui si è fermato.
  • Lo standard trunk- tags- branchesè richiesto layout per repository SVN.
  • L'URL SVN dato al git svn clonecomando arresta al livello immediatamente superiore trunk/, tags/e branches/.
  • Il git svn clonecomando produce un sacco di output, inclusi alcuni avvisi in alto; Ho ignorato gli avvertimenti.

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 farlo funzionare su Windows era uno scherzo. Altre soluzioni non funzionavano con i percorsi Cygwin. Anche una volta che ho ottenuto qualcosa, 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 in alto, e funziona alla grande. La soluzione non deve essere più complicata di così!


Se hai commesso spazzatura ma non spinto,

git reset --soft HEAD~1

HEAD ~ 1 è una scorciatoia per il commit prima della testa. In alternativa è possibile fare riferimento allo SHA-1 dell'hash se si desidera ripristinare. L' opzione --soft cancellerà il commit ma lascerà tutti i file modificati "Changes to be committed", come lo avrebbe dichiarato lo stato git.

Se si desidera eliminare eventuali modifiche ai file tracciati nell'albero di lavoro poiché il commit prima di testa usa invece " --hard ".

O

Se hai già spinto e qualcuno ha tirato che di solito è il mio caso, non puoi usare git reset . Puoi comunque fare un git revert ,

git revert HEAD

Questo creerà un nuovo commit che inverte tutto ciò che viene introdotto dal commit accidentale.





svn git version-control git-svn