Perché gli utenti Git affermano che Subversion non ha tutto il codice sorgente localmente?

23

Sto solo andando su quello che ho letto su SO, quindi perdonami, ma tutto quello che ho letto dice che uno dei principali vantaggi di Git su Subversion è che Git fornisce tutto il codice sorgente allo sviluppatore localmente, senza dover fare nulla su il server.

Con il mio uso limitato di SVN e TortoiseSVN, avevo tutto il codice sorgente, o almeno pensavo di averlo fatto. Ad esempio, ho un sito Web. Lo carico su SVN. Sto ancora gestendo il mio sito Web localmente, vero? Se qualcuno invia una modifica e non sono connesso, non importerebbe se avessi Git o meno, fino a quando non mi riconnetterò al server.

Non capisco. Non sto chiedendo una revisione dell'uno contro l'altro, tranne questo punto.

git svn

— Johnny
fonte

2

Non è che hai tutto il tuo codice sorgente localmente, è che hai l'intera cronologia del repository localmente. Ciò rende molto più veloci tutte le interazioni del repository diverse dalla sincronizzazione del server.

— stonemetal

69

La premessa di cui ti stai interrogando è davvero sbagliata:

quel grande vantaggio di Git su Subversion è che Git fornisce tutto lo codice sorgente allo sviluppatore localmente

Con Subversion e Git hai il tuo codice sorgente localmente. Con Git hai sia il tuo codice sorgente che un repository sul tuo computer locale.

Va qualcosa del genere.

Sovversione:

Il tuo codice <-> Il repository

Idiota:

Il tuo codice <-> Il tuo repository locale <-> Un repository remoto (... <-> un altro repository remoto e così via)

Un vantaggio che si ottiene da questa struttura è che è ancora possibile utilizzare il controllo del codice sorgente e eseguire il commit delle modifiche locali nel repository locale senza disturbare il lavoro degli altri membri del team (con i quali si condivide il repository remoto).

Con Subversion dovresti rischiare di rompere la costruzione per altre persone o subire uno sviluppo locale prolungato senza alcun controllo delle fonti che termina con un enorme impegno (o più probabilmente un ritorno).

Con Git, d'altra parte, ti sentiresti libero di impegnare queste modifiche nel tuo repository locale, visualizzare i registri e le differenze o le tue modifiche e solo quando ritieni che sia pronto per essere condiviso con il team, spingi le modifiche dal locale repository a quello remoto.

— Goran Jovic
fonte

10

Questa è una risposta molto bella e colpisce davvero con "... rischia di rompere l'edificio per altre persone o subire uno sviluppo locale prolungato senza alcun controllo delle fonti ..."

— Charles Sprayberry

1

@cspray: grazie! Sono sicuro che ci sono anche altri vantaggi, ma questo è il più grande dolore che ho avuto con Svn.

— Goran Jovic,

git FTW (altri 8 per andare ...)

— Trevor Boyd Smith,

2

@DanNeely: In realtà lo fa - OP ha chiesto un reclamo che ha letto da qualche parte e la risposta è che semplicemente non è vero (vedi la prima parte della mia risposta). La seconda parte è solo una spiegazione di ciò che chiunque abbia fatto la richiesta probabilmente voleva dire e perché.

— Goran Jovic,

1

@Giorgio: provalo e lo saprai :) Seriamente, non credo di essere mai riuscito a farlo senza problemi (a parte fare una fusione completamente manuale, che tipo di sconfigge lo scopo dello strumento)

— Goran Jovic,

17

Git o Mercurial memorizzano l'intero repository localmente con tutte le revisioni e le filiali con nome. Subversion ne memorizza solo una, di solito la Revisione principale. Quindi con Git e Mercurial puoi accedere al repository completo (ovvero il tuo codice sorgente attuale e la sua cronologia) anche quando la tua rete si rompe con SVN sei limitato all'ultima revisione a cui sei aggiornato.

— Amenti
fonte

1

@Murph Grazie. Questo era essenzialmente ciò che intendevo. Ho cercato di chiarire.

— Amenti,

Non è solo una questione di avere una connessione di rete al server o no; l'IO locale è molto più veloce e una latenza inferiore rispetto all'IO di rete, il che rende l'esame della cronologia o l'incolpazione di un file molto più veloce (avviso di colpa di TrotiseSVN "Attendere - l'operazione può richiedere alcuni minuti. Davvero!"). Il compromesso è che avere tutta la cronologia locale può richiedere molto più spazio su disco in repository più grandi; questo può essere problematico sui laptop dove non si può semplicemente aggiungere un disco aggiuntivo per integrare un SSD più piccolo non infrangibile.

— Dan Neely,

Il commento di @ DanNeely era probabilmente ragionevole nel 2012, ma 4 anni dopo è quasi impossibile trovare un progetto git che possa occupare qualsiasi porzione considerevole di un SSD

— Igor Stoppa,

7

La risposta breve è questa: con git hai tutto il tuo codice sorgente, con sovversione hai tutta la versione più recente del tuo codice sorgente.

Git conserva localmente una copia dell'intera cronologia del repository. Con sovversione l'intera cronologia è su un server.

— Bryan Oakley
fonte

2

Penso che ciò che potresti ottenere è che con SVN, tutte le tue azioni richiedono la comunicazione con il server, mentre GIT no. Con SVN, se si desidera ramificare, si ramifica sul server e si abbassa quel ramo. Con GIT, è possibile creare una filiale locale senza che il "server" ne sia a conoscenza.

Hai ragione nel dire che hai il codice sorgente sia con SVN che con GIT, ma con GIT non c'è bisogno di un server centralizzato che contenga anche il codice sorgente. Con GIT, potresti essere l'UNICA persona con il codice sorgente, ma essere comunque in grado di svolgere tutte le funzioni che faresti con un tipico VCS.

Ho sentito argomenti contro GIT e penso che ciò possa aiutare con la tua domanda, dicendo che poiché non ti è richiesto di impegnarti in un repository centrale, possiedi il tuo codice sorgente fino a quando non lo hai impegnato e trasferito sul tuo server, se Ne hai uno. Con SVN, l'unico modo per avere il controllo della versione è affidarsi al server, ma con GIT, potresti potenzialmente conservare tutto sul tuo computer locale e se qualcosa va storto, "potresti perdere tutto" anche se potresti altrettanto facilmente perdere tutte le modifiche con SVN se non si è eseguito il commit e anche l'HDD si è bloccato.

— David Peterman
fonte

1

dicendo che, poiché non è necessario eseguire il commit in un repository centrale, si possiede il codice sorgente fino a quando non si è eseguito il commit e il push sul server, se ne si possiede uno. Con SVN, l'unico modo per avere il controllo della versione è affidarsi al server, ma con GIT, potresti potenzialmente conservare tutto sul tuo computer locale e se qualcosa va storto, "potresti perdere tutto" anche se potresti altrettanto facilmente perdere tutte le modifiche con SVN se non si è eseguito il commit e anche l'HDD si è bloccato.

Se spingi quotidianamente, il rischio dovrebbe essere piccolo. Ma se sei costretto a impegnarti quotidianamente sul server SVN, alla fine della giornata, puoi fare tutto in un unico grande changeset, che non separa ogni modifica in piccoli passi. Con Git, sei incoraggiato a fare più piccoli commit. Quando si spinge, se è necessaria la fusione, provare a unire e spingere. Se al momento non è possibile unire, è possibile eseguire il push in un nuovo ramo o in un altro repository sul server.

— linquize
fonte