Perchè strumenti come git-svn che permettono a git di integrarsi con svn utile? [chiuso]

Costringere un'azienda a passare da un VCS a un altro è una decisione importante da prendere. Git è una grande curva di apprendimento per le persone che hanno utilizzato SVN, indipendentemente da quello che le persone dicono. Se hai una squadra di 30 persone, non importa quanto sia buona l'idea di un passaggio a Git, è una decisione importante.

Ma, se preferisci un DVCS (lo faccio, solo per la possibilità di eseguire commit veloci, regolari, senza doverli spingere sul server di build), non dovrebbe esserci nulla che ti impedisca, personalmente, di usarlo, senza causare problemi interruzione per tutti gli altri. Dopotutto, DVCS è solo la capacità di clonare un database centrale e poi clonarlo ancora e ancora.

E questo è ciò che Git-Svn (o anche Git-tf) fa per te. Nessun altro ha nemmeno bisogno di sapere che lo stai usando.

Lentamente, puoi convertire le persone sul lato oscuro e, se c'è ancora abbastanza movimento pro-Git per renderlo utile a tutti, puoi spostare il repository centrale su Git.

Uso git-svn perché utilizzo le mie filiali locali (e PRIVATE) per organizzare il mio flusso di lavoro e per sperimentare. Con centralizzato non riesco a creare un ramo a meno che non sia sul server a cui tutti gli altri hanno accesso. Suppongo che si possano impostare autorizzazioni / gruppi speciali sul server in modo tale che quando si crea un ramo solo io abbia accesso ma TBH sembra più un lavoro del necessario.

E ci stiamo muovendo per diventare il nostro SCM centrale, sono solo pochi mesi ma consente agli sviluppatori di imparare git senza dover modificare l'intera infrastruttura.

L'utilizzo di Git combinato con SVN può essere utile se il tuo sviluppo si svolge in base a rigide regole di check-in. Ad esempio, il controllo nel repository centrale può richiedere revisioni tra pari, casi di test unitari, documenti di progettazione e diversi moduli cartacei.

Sebbene queste regole siano buone, rendono il check-in al server centrale un onere. Ho scoperto che gli sviluppatori tendono ad aspettare e fare un gigantesco check-in per consolidare il lavoro su carta.

Con GIT puoi effettuare il check-in a livello locale in modo da avere molti piccoli punti di salvataggio durante lo sviluppo. È solo il disco locale, quindi non è necessario eseguire peer-review, documenti cartacei o documenti di test unitari.

Durante lo sviluppo ottieni un set molto più ricco di punti di salvataggio. E i punti di salvataggio sono l'intero punto di utilizzo del controllo del codice sorgente (rispetto ai backup obsoleti).

Un altro punto da sottolineare è che è meno probabile che uno sviluppatore di un progetto stia "andando fuori di testa" e usi git mentre il resto del team usa SVN, ma è probabile che un gruppo completamente diverso di sviluppatori voglia usare e sviluppare un progetto che usa SVN e questo gruppo preferisce git.

Ad esempio, il nostro gruppo utilizza un software di chimica open source che è ospitato online con SVN. Ma abbiamo dei cambiamenti che facciamo internamente che non lasceranno il nostro gruppo e tutti noi conosciamo il git. Quindi piuttosto che forzare tutti ad imparare entrambi, lasciamo che uno o due esperti escogitino git-svn e clonino il progetto in un repository interno. E poi i nostri processi di sviluppo continuano senza problemi.

Anche se non dovessimo apportare modifiche, alcune persone non sono programmatori e non possono (o davvero non vogliono) imparare come usare git e SVN. Quindi forniamo un passaggio intermedio per quegli utenti, tutto quello che devono sapere è come clonare con git.

Il mio ragionamento è un po 'meno sofisticato rispetto agli altri ragazzi - ma è soprattutto la combinazione del meglio di entrambi i mondi (le mie filiali locali, la scorta, distaccata dal repository principale).

Per quanto riguarda il vantaggio di mantenere SVN - numero di revisione unico per tutti - a partire da supporto, sviluppatori, manager ... fino al direttore generale. E sì - sono consapevole di descrivere Git, ma sfortunatamente: ho bisogno di più di quello per convincere ppl.

Ci sono già molte buone risposte con alcuni motivi chiave come

• commit offline / privato / sperimentale
• Scambia all'interno di piccoli sottogruppi all'esterno dell'albero principale di svn

Ma secondo me c'è un altro motivo importante per usare git-svn per i progetti svn: Cronologia rapidamente accessibile . Con svn hai bisogno di una connessione di rete per qualcosa di più di un semplice svn diff . A seconda della posizione in cui si trova il server del repository e il carico del server che esamina la cronologia per trovare i motivi per un potenziale bug o simili può essere piuttosto lento. Con git dipende solo dalla velocità del tuo disco locale. e poi, grazie alla compressione di git, molte operazioni relative alla cronologia sono abbastanza veloci.