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

La premessa che stai facendo è davvero sbagliata:

that one major advantage of Git over Subversion is that Git gives all the source code to the developer locally

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

Va qualcosa di simile.

Subversion:

Il tuo codice < - > Il repository

Git:

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

Un vantaggio derivante da questa struttura è che puoi ancora utilizzare il controllo del codice sorgente e trasferire le modifiche locali al tuo repository locale senza disturbare il lavoro degli altri membri del team (con cui condividi il repository remoto).

Con Subversion dovresti rischiare di rompere la build per altre persone o subire uno sviluppo locale prolungato senza alcun controllo del codice sorgente che finisca con un commit enorme (o più probabilmente un ripristino).

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

Git o Mercurial memorizzano l'intero repository localmente con tutte le revisioni e i rami con nome. Subversion ne memorizza solo una - di solito la Revisione iniziale. Quindi con Git e Mercurial puoi accedere al repository completo (cioè il tuo codice sorgente attuale e la sua cronologia) anche quando la tua rete si guasta con SVN sei limitato all'ultima revisione che hai aggiornato.

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

Git mantiene una copia dell'intera cronologia del tuo repository localmente. Con sovversione l'intera cronologia si trova su un server.

Penso che quello che potresti ottenere è che con SVN tutte le tue azioni richiedono la comunicazione con il server, laddove GIT no. Con SVN, se si desidera diramazione, si dirama sul server e si abbassa quel ramo. Con GIT, puoi creare una filiale locale senza che il "server" ne sia a conoscenza.

Hai ragione nel dire che hai il codice sorgente con SVN e 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 ancora in grado di fare tutte le funzioni che vorresti con un tipico VCS.

Ho sentito argomenti contro GIT, e penso che questo possa aiutare con la tua domanda, dicendo che dal momento che non sei obbligato a impegnarti in un repository centrale, possiedi il tuo codice sorgente fino a quando non lo hai commesso e trasferito al tuo server, se ne hai uno. Con SVN, l'unico modo per avere il controllo della versione è il commit sul server, ma con GIT, potresti potenzialmente tenere 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 hai commesso e anche il tuo HDD si è bloccato.

saying that since you're not required to commit to a central repo, you own your source code until you have committed and pushed it to your server, if you have one. With SVN, the only way to have the version control is by committing to the server, but with GIT, you could potentially keep everything on your local machine and if any goes wrong, you "could lose everything" even though you could just as easily lose all your changes with SVN if you didn't commit and your HDD crashed as well.

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