Ricerca…
Osservazioni
Clonazione di repository SVN davvero grandi
Se la cronologia dei repository SVN è davvero molto grande, questa operazione potrebbe richiedere ore, dato che git-svn ha bisogno di ricostruire la cronologia completa del repository SVN. Fortunatamente è sufficiente clonare il repository SVN una sola volta; come con qualsiasi altro repository git, è sufficiente copiare la cartella repo in altri collaboratori. Copiare la cartella su più computer sarà più veloce che basta clonare grandi repository SVN da zero.
Informazioni su commit e SHA1
I tuoi commit git locali verranno riscritti quando si usa il comando git svn dcommit . Questo comando aggiungerà un testo al messaggio del commit git che fa riferimento alla revisione SVN creata nel server SVN, che è molto utile. Tuttavia, l'aggiunta di un nuovo testo richiede la modifica di un messaggio di commit esistente che non può essere effettivamente fatto: git commits sono immutabili. La soluzione è creare un nuovo commit con gli stessi contenuti e il nuovo messaggio, ma è tecnicamente un nuovo commit in ogni caso (cioè lo SHA1 di git commit cambierà)
Poiché i commit git creati per git-svn sono locali, gli ID SHA1 per i commit git sono diversi tra ciascun repository git! Ciò significa che non è possibile utilizzare uno SHA1 per fare riferimento a un commit da un'altra persona poiché lo stesso commit avrà un diverso SHA1 in ciascun repository git locale. È necessario fare affidamento sul numero di revisione svn aggiunto al messaggio di commit quando si preme sul server SVN se si desidera fare riferimento a un commit tra diverse copie del repository.
Puoi comunque usare SHA1 per le operazioni locali (mostra / diff uno specifico commit, cherry-pick e reset, ecc)
Risoluzione dei problemi
Il comando git svn rebase emette un errore di non corrispondenza del checksum
Il comando git svn rebase genera un errore simile a questo:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
La soluzione a questo problema è ripristinata svn alla revisione quando il file in difficoltà è stato modificato per l'ultima volta, e fa un git svn fetch in modo che la cronologia SVN venga ripristinata. I comandi per eseguire il reset SVN sono:
- git log -1 -
<path_to_file>(copia il numero di revisione SVN che appare nel messaggio di commit) - git svn resetta
<revision_number> - git svn fetch
Dovresti essere in grado di spingere / tirare di nuovo i dati da SVN
Il file non è stato trovato nel commit Quando si tenta di recuperare o estrarre da SVN si ottiene un errore simile a questo
<file_path> was not found in commit <hash>
Ciò significa che una revisione in SVN sta tentando di modificare un file che per qualche motivo non esiste nella copia locale. Il modo migliore per sbarazzarsi di questo errore è forzare un recupero a ignorare il percorso di quel file e verrà aggiornato al suo stato nell'ultima versione di SVN:
-
git svn fetch --ignore-paths <file_path>
Clonazione del repository SVN
È necessario creare una nuova copia locale del repository con il comando
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Se il repository SVN segue il layout standard (trunk, rami, cartelle tag) è possibile salvare alcuni tipi di digitazione:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone controlla ogni revisione SVN, una per una, e crea un commit git nel tuo repository locale per ricreare la cronologia. Se il repository SVN ha molti commit, questo richiederà un po 'di tempo.
Al termine del comando, si avrà un repository git completo con un ramo locale chiamato master che tiene traccia del ramo trunk nel repository SVN.
Ottenere le ultime modifiche da SVN
L'equivalente di git pull è il comando
git svn rebase
Ciò recupera tutte le modifiche dal repository SVN e le applica sopra i commit locali nel ramo corrente.
Puoi anche usare il comando
git svn fetch
per recuperare le modifiche dal repository SVN e portarle sul computer locale, ma senza applicarle al ramo locale.
Spingendo le modifiche locali su SVN
Il comando
git svn dcommit
creerà una revisione SVN per ciascuno dei tuoi commit git locali. Come con SVN, la cronologia git locale deve essere sincronizzata con le ultime modifiche nel repository SVN, quindi se il comando fallisce, provare prima a eseguire git svn rebase .
Lavorare localmente
Basta usare il repository git locale come normale repository git, con i normali comandi git:
-
git add FILEegit checkout -- FILEPer mettere in scena / rimuovere un file -
git commitPer salvare le modifiche. Questi commit saranno locali e non saranno "spinti" al repository SVN, proprio come in un normale repository git -
git stashegit stash popConsente l'uso di stash -
git reset HEAD --hardRipristina tutte le modifiche locali -
git logAccedi a tutta la cronologia nel repository -
git rebase -imodo che tu possa riscrivere liberamente la tua cronologia locale -
git branchegit checkoutper creare filiali locali
Come afferma la documentazione di git-svn "Subversion è un sistema molto meno sofisticato di Git" quindi non puoi usare tutta la potenza di git senza rovinare la cronologia nel server Subversion. Fortunatamente le regole sono molto semplici: mantieni lineare la storia
Ciò significa che puoi eseguire quasi tutte le operazioni git: creare rami, rimuovere / riordinare / schiacciare i commit, spostare la cronologia, eliminare i commit, ecc. Tutto tranne unioni . Se hai bisogno di reintegrare la cronologia delle filiali locali, usa invece git rebase .
Quando si esegue un'unione, viene creato un commit unione. La particolarità di unire commit è che hanno due genitori e ciò rende la cronologia non lineare. La cronologia non lineare confonderà SVN nel caso in cui "spinga" un commit di unione al repository.
Comunque non preoccuparti: non romperai nulla se "spingi" un commit di git merge su SVN . Se lo fai, quando il commit di git merge viene inviato al server svn, conterrà tutte le modifiche di tutti i commit per quell'unione, quindi perderai la cronologia di quei commit, ma non le modifiche nel tuo codice.
Gestione di cartelle vuote
git non riconosce il concetto di cartelle, funziona solo con i file e con i loro percorsi di file. Ciò significa che git non tiene traccia delle cartelle vuote. SVN, tuttavia, lo fa. L'uso di git-svn significa che, per impostazione predefinita, qualsiasi modifica che fai coinvolgendo cartelle vuote con git non verrà propagata a SVN .
L'uso del flag --rmdir durante l'emissione di un commento corregge questo problema e rimuove una cartella vuota in SVN se elimini localmente l'ultimo file al suo interno:
git svn dcommit --rmdir
Sfortunatamente non rimuove le cartelle vuote esistenti : devi farlo manualmente.
Per evitare di aggiungere il flag ogni volta che si esegue un dcommit, o di giocare sul sicuro se si utilizza uno strumento GUI git (come SourceTree) è possibile impostare questo comportamento come predefinito con il comando:
git config --global svn.rmdir true
Questo cambia il tuo file .gitconfig e aggiunge queste righe:
[svn]
rmdir = true
Per rimuovere tutti i file e le cartelle non tracciati che devono essere mantenuti vuoti per SVN, utilizzare il comando git:
git clean -fd
Nota: il comando precedente rimuoverà tutti i file non tracciati e le cartelle vuote, anche quelle che dovrebbero essere monitorate da SVN! Se hai bisogno di generare aga le cartelle vuote tracciate da SVN usa il comando
git svn mkdirs
In pratica ciò significa che se si desidera eseguire la pulizia dell'area di lavoro da file e cartelle non tracciabili, è necessario utilizzare sempre entrambi i comandi per ricreare le cartelle vuote tracciate da SVN:
git clean -fd && git svn mkdirs