Questa domanda è simile a this one e this one, ma lo scenario è leggermente più complesso.Come si comporta git-svn con i repository svn che hanno cambiato il layout?
Ho iniziato alcuni anni fa con un repository svn privato (che utilizzo principalmente per file di configurazione condivisi e simili tra varie macchine). Non ero troppo attento con il layout del repository (dove rami, vai, ecc.), Quindi è cambiato parecchio nel tempo. Questo era, naturalmente, un errore, ma ora è troppo tardi. Più recentemente, l'ho migrato a un layout svn trunk/branches/tag più standard, principalmente con i comandi svn move, ma ovviamente la vecchia storia è ancora presente nel repository (ed è, francamente, un po 'di confusione) .
Vorrei ora convertirlo definitivamente in un repository git. Ho provato a utilizzare git-svn, ma sembra solo gestire situazioni in cui è stata seguita una convenzione tronco/ramo/tag coerente (sì, è possibile fornire nomi alternativi, ma solo uno per ciascuno, viene visualizzato). Una parte considerevole della cronologia del mio repository ha un trunk efficace nella root del repository, ad esempio, con tag/e branches/come sub-dirs.
Qual è il modo migliore per gestire tutto questo? Idealmente mi piacerebbe che il repository git finisse per avere almeno tutta la cronologia accessibile in qualche modo, anche se i branch e i tag non sono correttamente rappresentati come concetti di prima classe in git.
In particolare, in che modo svn-git gestisce i file all'esterno delle sottodirectory trunk/branches/tags con cui è fornito? Le mie osservazioni finora sono che a volte le manca (sicuramente non è OK), e altre volte le aggiunge al nuovo repository.
Ogni pensiero sarebbe apprezzato.
Mi chiedi come va a comportarsi, ma anche dire che hai provato. Esempi specifici di comportamento indesiderato che hai osservato potrebbero essere utili. Git di solito è straordinariamente bravo a gestire le unioni complesse, ad esempio, alterando e spostando una sottostruttura nella stessa commit. –
OK - l'ho provato. Ammetto che non avrei potuto approfondire completamente i risultati, ma le mie osservazioni superficiali erano certamente che git-svn sembrava includere alcune directory dalla radice di svn (cioè all'esterno delle directory trunk/branches/tags), ma non altre. Ero confuso sul perché. git è sicuro di gestire fusioni complesse, ma penso che questa domanda riguardi più git-svn che git stesso. –
usa il tag ['svn'] invece del tag [' subversion'] http://meta.stackexchange.com/questions/2601/batch-retag-request-merge-svn-and-subversion –