Come gestire l'importazione di subversion non standard in Git

Question

Abbiamo un riposizionamento di sovversione non standard che vorremmo convertire in Git. Il problema è che in realtà non so da dove cominciare per essere sicuro di mantenere la cronologia completa ma non finire con un casino completo.

Il nostro repository ha gli ultimi 6 anni di storia per la suite di prodotti della nostra azienda e ha subito ristrutturazioni multiple. In tutti i casi abbiamo un codice base della piattaforma di base e quindi diversi progetti/plug-in che si combinano in modi diversi sulla parte superiore della piattaforma principale.

Il primo paio di anni è stato strutturato come:

-- plugin1 
    - trunk 
    - branches 
    - tags 
-- pluginX 
    - trunk 
    - branches 
    - tags 
-- trunk (core platform) 
    - <various sub dirs) 
-- branches (various feature branches of the entire repository) 
    - refactoring1 
    - refactoringX 
-- tags (various tags of customer releases of full respository) 
    - customerX_1.x 
-- vendor (vendor drops and tracking of 3rd party source deps) 
    - 3rd_party_code_A 
    - 3rd_party_code_X 

Nel corso del tempo abbiamo aggiunto un altro paio di directory sono la radice tra cui:

-- releases (replaced tags; branches for released stable versions of repos) 
-- sandbox (area for misc projects of interest; should have been new repo) 

Poi abbiamo ripulito questo e finito con:

-- trunk 
    - platform 
    - plugin1 
    - pluginX 
-- stable (stable release branches of trunk) 
    - 1.1 
    - 1.2 
-- tags (release points; marks a point on a stable branch) 
    - 1.1.1 
    - 1.1.2 
-- vendor 
-- sandbox 
-- releases (copies of old releases of interest) 

Questa è la nostra storia. Spero che ciò che vogliamo finire sia molto più pulito. In questo momento stiamo pensando alla base del repository git simile a questa (fondamentalmente una copia della precedente directory 'trunk').

- platform 
- plugin1 
- pluginX 

Branches: 
    - stable/1.1 
    - stable/1.2 
Tags: 
    - rel/1.1.1 
    - rel/1.1.2 

Vorremmo mettere sandbox e vendor nelle loro repository. (non so come fare, ma forse c'è un modo per importare solo un sottoinsieme di un repository svn)

Per quanto riguarda i rami e le etichette, vorremmo che il codice da "stabile" finisse come rami, il codice da 'tag' per finire come tag in stabile.

Per la cronologia precedente dalla struttura originale, vorremmo mantenere il maggior numero possibile di cronologia ma non vogliamo inquinare il nuovo repository. Ad esempio, se potessimo guardare indietro e vedere i cambiamenti avvenuti sui rami refactoring sarebbe fantastico ma non assolutamente necessario.

Attualmente stiamo discutendo su come procedere e come ottenere tutto ristrutturato e importato in modo pulito. Il minimo che ci serve è un modo per avere una cronologia completa della piattaforma e del codice del plug-in su entrambe le ristrutturazioni del repository precedenti. Se possibile, vorremmo anche ottenere le informazioni sulla stalla e sui tag dalla più recente struttura del repository.

Qualcuno ha consigli su come eseguire questa importazione?

Ad esempio:

• E 'possibile mantenere l'intero attraverso le ristrutturazioni?
• Dovremmo riscrivere il repository di subversion in qualche modo per ripulirlo prima dell'importazione e, in caso affermativo, come?
• Dovremmo importare la cronologia completa e quindi ristrutturarla in Git e in che modo?
• Qualche idea su come rendere pulita questa importazione?

Answer 1

A seconda della situazione, git-svn (con l'opzione di default --follow-parent) potrebbe solo fare il trucco come è. La prima cosa da fare è provare alcune esecuzioni di git-svn, specificando attentamente le opzioni -T, -b e -t per aiutarlo con la struttura delle directory.

È possibile che si verifichino problemi con una complicata cronologia delle strutture di directory.

Recentemente mi trovavo in una situazione molto simile, migrando il codice di Subversion della mia azienda a git, dove la storia SVN aveva attraversato una ristrutturazione molto simile a ciò che state descrivendo. Nel mio caso, volevo anche separare i progetti da un repository Subversion a più repository Git (uno per progetto).

Sono stato in grado di prendere la via più semplice, decidendo che non era fondamentale migrare più di qualche mese di storia, quindi per ogni progetto ho determinato quale fosse la prima revisione che git-svn poteva gestire con garbo, e quindi solo recuperato la cronologia a partire da lì (utilizzando git-svn -r). Avendo gestito precedenti migrazioni VCS (VSS a SVN, 2005), sapevo per esperienza che la storia a lungo termine non viene quasi mai menzionata. In ogni caso, è facile lasciare in esecuzione il vecchio server Subversion (in modalità di sola lettura), in modo che possa essere utilizzato per cercare le cose se necessario.

non so di un modo semplice per ripulire storia di Subversion, tranne usando svndumpfilter di escludere alcune parti di esso. Se sei fortunato, però, git-svn farà magicamente la cosa giusta e la cronologia apparirà effettivamente più pulita in git log di quanto non abbia mai fatto in svn log (a causa della differenza di come git guarda i rami e i tag).

In generale, la pulizia e completezza della storia sono due obiettivi contrastanti quando si fa una migrazione di questo tipo. Fortunatamente, sono entrambi davvero sopravvalutati - entrambi fanno appello al nostro senso estetico più che alle necessità pragmatiche.

EDIT: punta laterale per la pulizia: utilizzare l'opzione --prefix su git-svn, per dare i rami importati un prefisso unico, poiché è probabile che si avrà diverse convenzioni di ramificazione in git, e lo rende facile da vedere la storia svn più tardi.