Ho una certa esperienza con Perforce, SVN e TFS. Per SVN, i file di origine erano di default scrivibili dopo la sincronizzazione. Tuttavia, sono stati di sola lettura per Perforce, così come TFS se la memoria mi ha servito.
Nel frattempo, 'checkout' significa sincronizzazione sorgente per SVN, ma il suo significato è abbastanza diverso per altri strumenti popolari.
Mi chiedo quale sia il comportamento più 'corretto' e perché questi strumenti si comportano in modo diverso.
Grazie.
C'erano due modi o paradigmi diversi con il controllo del codice sorgente. Questi erano:
Il primo è stato usato da VSS, mentre svn usa il secondo di default.
(TFS si è evoluto da VSS e credo che Perforce abbia utilizzato cvs come punto di partenza)
Utilizzando il primo paradigma, quando ottieni i file dal repository, non hai detto che vuoi modificarli e il controllo del codice sorgente li contrassegna come readonly per costringerti a "estrarre in modo esplicito" per modificare il file che vuoi modificare . VSS aveva i comandi per 'ottenere l'ultima' e il checkout '- ed era il checkout che contrassegnava il campo come modificabile (e lo bloccava nel repository di default in modo che altri non potessero modificare lo stesso file allo stesso tempo).
Questo porta a problemi se uno sviluppatore estrae e blocca un determinato file e poi se ne va in congedo, ecc. I suoi colleghi non possono modificare il file senza interrompere il blocco o l'hacking nel suo account.
Subversion usa il secondo paradigma edit / fonde / commit. Non esiste un comando per 'ottenere l'ultima' senza la possibilità di modificare il file - c'è solo il comando checkout. Diversi sviluppatori possono modificare uno stesso file allo stesso tempo.
Questo porta ad altri problemi al commit. Se tu ed io abbiamo entrambi modificato lo stesso file e commetti prima le modifiche, non posso impegnare la mia versione senza prima unirmi alle tue modifiche. Qui c'è il rischio che io non capisca le modifiche che hai apportato e modifico il file in modo che faccia ciò che volevo e interrompa il cambiamento che hai fatto.
Entrambi i paradigmi hanno potenziali problemi, ma a mio parere il checkout / modifica / fusione è migliore. Se più sviluppatori stanno modificando gli stessi file contemporaneamente e hanno difficoltà a unire le modifiche, credo che tu abbia problemi con la struttura del codice e la comunicazione tra team che non può essere risolta solo con lo strumento di controllo del codice sorgente.
Per evitare il problema quando uno sviluppatore ha un file bloccato e non può essere contattato per rilasciare il blocco, alcuni sistemi di controllo del codice sorgente hanno consentito il blocco o l'override dei blocchi. Alcuni consentono inoltre di impostare il repository in modo tale che alcuni file non siano bloccati e quindi devono essere uniti prima di eseguire il commit, ovvero utilizzando un controllo / modifica / unione / commit amalgamati. A causa della loro provenienza, il loro comando 'get latest' ottiene una copia di sola lettura e insiste che si esegue il checkout per la modifica per ottenere una copia scrivibile, ma seguono lo stesso flusso di sovversione con la modifica e l'unione prima del commit . Ecco come funziona Perforce.
Per mitigare il problema di non poter unire le modifiche, Subversion consente di impostare il repository in modo da richiedere il blocco di alcuni o tutti i file. (Ho usato questo è il passato per garantire che la documentazione di MSWord che è stata difficile da unire potesse essere aggiornata solo da un utente alla volta, e allo stesso modo con immagini / icone.)
Leggi altre domande sui tag version-control svn team-foundation-server