svn to git migration: storia incompleta

Question

Sto migrando il mio repository SVN in base alla risposta this. Tutto va liscio, tranne che alla fine non ho la cronologia completa. Ho potuto rintracciare la fonte del problema fino a una "mossa SVN" che ho fatto.

Questo è quello che ho fatto: All'inizio il mio SVN pronti contro termine non ha avuto trunkbranchestags dirs. Quando li ho introdotti e spostato tutto nel bagagliaio (e poi ho creato un ramo, ecco perché ho deciso di introdurre la nuova struttura di cartelle).

Quindi dopo la migrazione del repository SVN per git solo la cronologia dopo l'introduzione della nuova struttura di cartelle è disponibile.

Ho riprodotto questo problema in uno scenario molto semplice.

Storia in SVN:

Storia in git:

La zip che contiene SVN repo/git repo:

https://www.dropbox.com/s/ecy54st05qah4up/svn_git_problem.zip?dl=0

Esiste un modo per risolvere questo problema ?

Answer 1

Quando si specifica --stdlayout, git svn clone si presterà attenzione solo ai commit svn che modificano i file in percorsi/trunk,/rami o/tag - gli altri commit verranno ignorati. Finisci comunque con un clone valido del tuo repository, ma la cronologia da r1 fino alla creazione del tuo layout standard andrà persa, come hai osservato. Dal momento che vuoi che il tuo repository Git comprenda trunk, branches e tag che seguono la modifica del layout, vuoi comunque --stdlayout, altrimenti git clone unirà tutti i rami in un singolo albero con/trunk/branches/tags, che non è quello che vuoi.

Cosa si può fare se si preoccupa profondamente della cronologia delle modifiche al layout (e se si tratta di una migrazione una tantum, nessun commit SVN dopo il passaggio a Git), è necessario eseguire git svn clone due volte - una volta con --stdlayout e una volta senza. La versione stdlayout diventerà il tuo repository finale e la versione non-stdlayout può essere utilizzata solo durante la migrazione, per ricucire la cronologia delle modifiche pre-layout sotto il nuovo layout, nel punto della riorganizzazione. Questo può essere fatto selezionando a fondo tutti i tuoi commit post-reorg su un'istantanea del repository al momento del re-org.

Dopo aver clonato entrambi i repository, noterete che al punto della copia nel nuovo layout, c'è un albero comune per il trunk. Ecco un esempio (non usare il repo dispiace, così hash differiscono):

(in stdlayout repo):

# git log --pretty=raw 
commit 44f2f60e00117dfd51fd7d6431b697ec0ccc863d 
tree 5cf62e006bb7b58171010fc0ffaba08ca97520da 
parent d403c6ce0789cf584af9abb945bcfd88721e391e 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000 

    change 4 after folder structure & branch 

    git-svn-id: http://<redacted>/trunk@9 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit d403c6ce0789cf584af9abb945bcfd88721e391e 
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3 
parent 0c5873eab204942ffe56370cc6e1d31e5372da13 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000 

    changed: moved to new folder structure 

    git-svn-id: http://<redacted>/trunk@7 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit 0c5873eab204942ffe56370cc6e1d31e5372da13 
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000 

    new folder structure 

    git-svn-id: http://<redacted>/trunk@6 4ed80924-4846-11e4-8279-c5809b3f22e4 

(nel pieno, pronti contro termine non stdlayout):

commit ec52fff6ee1d65eadfa1d18aa4b74b553fc693e1 
tree cfda32eb39248fa5969d15a21d2f8014189e88c2 
parent 685fe9961abfee4d4913e83cf5a4a7e8d459a1a1 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000 

    change 4 after folder structure & branch 

    git-svn-id: http://<redacted>@9 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit 685fe9961abfee4d4913e83cf5a4a7e8d459a1a1 
tree 817306fad0ed5466d877437cdda12ff39a0df725 
parent 02caf52174c588f1d394815201b764f9abdaa640 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411565 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411565 +0000 

    created new branch 

    git-svn-id: http://<redacted>@8 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit 02caf52174c588f1d394815201b764f9abdaa640 
tree c041405a580beaef0a4e50923e9279e179c917a8 
parent 37d77b8f1168d00b943e0bca3cab277cf89e7e84 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000 

    changed: moved to new folder structure 

    git-svn-id: http://<redacted>@7 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit 37d77b8f1168d00b943e0bca3cab277cf89e7e84 
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3 
parent 3a4784719bd95af5bf59de96310a1d6a38af562e 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000 

    new folder structure 

    git-svn-id: http://<redacted>@6 4ed80924-4846-11e4-8279-c5809b3f22e4 

commit 3a4784719bd95af5bf59de96310a1d6a38af562e 
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3 
parent 2fb41dab5a7389ab32419b8b270d955631aaaefa 
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411421 +0000 
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411421 +0000 

    update 4 

... etc., continues. 

si noti che nel repository stdlayout, commettere d403c6c è albero d6c0d6c, e nel pieno clone, sia impegna 37d77b8 e la controllante 01.233.958,835406 millionshanno anche lo stesso albero.Potresti pensare questo strano all'inizio, finché non ti rendi conto che la creazione di/trunk/branches/tags nel clone git-svn è in realtà un no-op, poiché Git non traccia le directory vuote.

Nel repo stdlayout, è possibile importare il full-clone di clone non standard:

# git remote add fullclone ../fullclone 
# git fetch fullclone 

Poi checkout un nuovo ramo della "nuova struttura di cartelle" commit dalla piena repo:

# git checkout -b fix-history 37d77b8 

rigiocare tutti i commit da questo punto in avanti nel repository standard di layout:

# git cherry-pick d403c6c..master 

Questo potrebbe richiedere un po 'di tempo per essere eseguito se si hanno molti commit post-org, poiché ogni commit viene reimpegnato sul nuovo ramo. Il risultato dovrebbe essere una storia combinata del tronco pre e post la riorganizzazione.