Come fare git-svn recuperare e mantenere la directory vuota?

Question

Ho creato uno script semplice per migrare un repository SVN abbastanza grande. Invece di usare git svn clone, sto usando git svn init e git svn fetch in modo da poter specificare la revisione e recuperarla in blocco. Più o meno, è qualcosa di simile:

while [ "$CURRENT_REVISION" -lt "$MAX_REVISION" ]; do 
    END_REVISION=$((CURRENT_REVISION + 100)) 
    if [ "$END_REVISION" -ge "$MAX_REVISION" ] 
    then 
    END_REVISION=$MAX_REVISION 
    fi 

    git svn fetch -r "$CURRENT_REVISION":"$END_REVISION" --authors-file="$AUTHORS_FILE" 

    #increasing the current and end revision 
    CURRENT_REVISION=$END_REVISION 
    END_REVISION=$((CURRENT_REVISION + 100)) 
done 

Tuttavia, ho capito che di default il comportamento del recupero/clone non manterrà le directory vuote. Quindi, potrei aver bisogno di controllare manualmente quelle directory vuote (* che sto cercando di evitare).

C'è un parametro --preserve-empty-dirs nello git svn clone ma non in git svn fetch.

Esiste una soluzione alternativa per risolvere il problema?

UPDATE

Anche se non è menzionato nella documentazione ufficiale che siamo in grado di utilizzare la chiave di configurazione per l'recuperare, è in realtà funziona

C'è spiegazione dettagliata da @Vampire relative a questo domanda. Quindi semplificherò questo.

Dopo aver fatto il repository init, ho dovuto cambiare la configurazione del mio ramo remoto:

git config svn-remote.<remote name>.preserve-empty-dirs "true"

git config svn-remote.<remote name>.placeholder-filename ".gitkeep"

È possibile verificare la configurazione, cercando in /.git/config. Basta fare il recupero normale e la tua directory sarà preservata.

Answer 1

git-svn è non lo strumento giusto per le conversioni una tantum dei repository. Si tratta di un ottimo strumento se si desidera utilizzare Git come frontend per un server SVN esistente, ma per le conversioni una tantum è necessario non utilizzare git-svn, ma svn2git che è molto più adatto per questo caso d'uso.

Ci sono strumenti pleny chiamati svn2git, il migliore probabilmente quello di KDE da https://github.com/svn-all-fast-export/svn2git. Consiglio vivamente di utilizzare lo strumento svn2git. È il migliore che io conosca disponibile là fuori ed è molto flessibile in quello che puoi fare con i suoi file di regole.

Se non si è al 100% circa la cronologia del proprio repository, svneverever da http://blog.hartwork.org/?p=763 è un ottimo strumento per indagare la cronologia di un repository SVN durante la migrazione a Git.

---

Se si vuole ancora utilizzare git svn, non c'è bisogno di Hunk manally tuo recupero. Basta fare git svn clone ..., se si desidera mettere in pausa, annullare l'esecuzione e quindi fare git svn fetch per continuare il processo di recupero. Continuerà automaticamente dove ha smesso di funzionare e persino convalidare l'ultima revisione recuperata sul fatto che sia stata recuperata completamente o che debba essere recuperata.

---

Se si vuole ancora Hunk manualmente il recupero, essere consapevoli che git svn clone ... è esattamente lo stesso di git svn init ... seguita da git svn fetch, con l'eccezione che in base ai clone parametri specifici delle proprietà di configurazione svn-remote.<remote name>.preserve-empty-dirs è impostato per true e svn-remote.<remote name>.placeholder-filename è impostato sull'argomento specificato tra init e fetch. Quindi fallo manualmente dopo il tuo init e prima del tuo recupero e stai bene.

Una nota però:preserve-empty-dirs afair è necessaria solo se è necessario disporre di queste directory vuote nel repository Git e si sta utilizzando solo il repository Git dopo. Finché si utilizza solo git svn come frontend per un repository SVN esistente, le directory emtpy dovrebbero essere create automaticamente nell'area di lavoro e non devono necessariamente far parte della cronologia attuale del repository. Quello che fa preserve-empty-dirs consiste nell'aggiungere un file vuoto .gitignore (o qualsiasi cosa tu abbia configurato con l'altra proprietà parametro/config) al commit, in modo che la cartella non sia più vuota. Questo è fatto in quanto Git è un tracker di contenuti, non un tracker di filesystem. Tiene traccia del codice sorgente che è archiviato nei file, non nei file e nelle cartelle stesse. Questo è anche il motivo per cui non esiste una esplicita operazione move o copy in Git, perché le mosse e le copie sono determinate al volo dove necessario e voluto. Tecnicamente è solo un remove e add per move o un semplice add per copy.