A che punto è necessario il controllo della versione? [duplicare]

Come lo descrivi, hai già una sorta di controllo di versione, anche se attualmente ci sono alcuni problemi con esso rispetto a un controllo di versione tipico:

Un commit intenzionale nel controllo della versione indica che lo sviluppatore crede fermamente che lo stato corrente del sistema possa essere realizzato correttamente.

(Esistono eccezioni, come suggerito da Il commento di Jacobm001 . In effetti, sono possibili diversi approcci e alcuni team preferirebbero non provare a rendere possibile ogni commit possibile: un approccio è avere build notturni, dato che durante il giorno il sistema potrebbe ricevere diversi commit che non costruiscono.)

Dato che non hai commit, il tuo sistema spesso genera uno stato che non genera. Questo ti impedisce di impostare l'integrazione continua .

A proposito, un sistema di controllo delle versioni distribuito ha un vantaggio: si può fare il commit locale quanto necessario mentre si porta il sistema in uno stato in cui non può essere generato, e quindi fare un commit pubblico quando il sistema è in grado di costruire .

1. Il controllo della versione ti consente di applicare alcune regole sul commit . Ad esempio, per i file Python, è possibile eseguire PEP 8, impedendo il commit se i file impegnati non sono conformi.

2. La colpa è estremamente difficile da fare con il tuo approccio.

3. Esplorando quali modifiche sono state apportate quando e da chi è troppo difficile. Controllo della versione log , l'elenco dei file modificati e a diff è un modo eccellente per trovare esattamente ciò che è stato fatto.

4. Qualsiasi unione sarebbe un dolore (o forse gli sviluppatori non vedrebbero nemmeno che i loro colleghi stiano modificando i file prima di salvare le modifiche). Hai dichiarato che:

   It's rare that the same project is worked on by two programmers

   Rare non significa mai, quindi le fusioni si verificano prima o poi.

5. Un backup ogni quindici minuti significa che gli sviluppatori potrebbero perdere fino a quindici minuti di lavoro . Questo è sempre problematico: è difficile ricordare esattamente quali cambiamenti sono stati fatti nel frattempo.

6. Con il controllo del codice sorgente puoi avere messaggi di commit significativi. Con i backup tutto quello che sai è che sono passati x minuti dall'ultimo backup.

Un controllo di versione reale garantisce che è sempre possibile ripristinare il commit precedente; questo è un enorme vantaggio. Ripristinare un backup usando il tuo sistema sarebbe un po 'più difficile di un rollback con un clic , che puoi fare nella maggior parte dei sistemi di controllo delle versioni. Inoltre, nel tuo sistema Branching è impossibile.

C'è un modo migliore per eseguire il controllo della versione e dovresti considerare di cambiare il modo in cui lo fai attualmente. Tanto più che, come Eric Lippert menziona , il tuo sistema attuale è probabilmente molto più doloroso da gestire rispetto a qualsiasi altro sistema di controllo di versione comune. Ad esempio, disporre di un repository Git o Mercurial su un'unità di rete è semplice.

Nota: anche se passi a un sistema di controllo versione comune, dovresti comunque avere un backup giornaliero / settimanale dei repository. Se stai utilizzando un sistema distribuito, è meno importante, poiché da quel momento la copia di lavoro di ogni sviluppatore è anche un backup.

Solo la mia opinione personale: il controllo della versione è utile per tutto ciò che richiede più di mezza giornata o che comporta un sacco di tentativi ed errori - o entrambi, naturalmente. Se coinvolge due o più persone che non utilizzano sempre la stessa tastiera e monitor, è essenziale.

Il costo dell'utilizzo di un sistema di controllo delle versioni formale, oltre la curva di apprendimento iniziale, è trascurabile. Inizializzazione di un repository? Due secondi. Aggiungere file? Un secondo. Poter tornare a quello che ho provato stamattina e discutere di ciò che ho scartato con il mio collega? Vale la pena ore o giorni, facilmente.

Il controllo delle versioni era sempre necessario, anche prima di aver hackerato il tuo "ma, eseguiamo il backup molto spesso!" kludge.

Il controllo della versione consente di pubblicare tali modifiche su tutti i file che appartengono a una funzione logica come un'unità. Se hai bisogno di rivedere "cosa era necessario per l'ordinamento senza distinzione tra maiuscole e minuscole in quella maschera?", Ti dice tutte le modifiche rilevanti e sopprime quelle irrilevanti.

Il controllo della buona versione tiene traccia dei nomi dei file, dei metadati e della provenienza di ogni singola riga di codice.

Il controllo della versione ti consente di contrassegnare tutte le modifiche con il motivo per cui le hai create.

Il controllo della versione non significa consentire a più di una persona di lavorare insieme. Si tratta di garantire la registrazione storica del codice base. Con la certezza che non puoi perdere nulla, o anche dimenticare quando lo hai fatto e come, sei libero di refactoring, inventare e creare senza paura. E non sai cos'è l'assenza di paura prima di averlo provato.

Il controllo della versione è molto utile anche come singolo sviluppatore e potrebbe essere un po 'più semplice del sistema di backup / copia file che hai ora.

• In questo momento, hai la possibilità di ottenere la versione precedente del codice, ma come trovi la versione che desideri?
• Solo la possibilità di fare una differenza tra le revisioni sarà molto preziosa. L'integrazione con gli strumenti di sviluppo è un altro vantaggio che non ottieni dai tuoi strumenti attuali.
• Un altro vantaggio sostanziale è la possibilità di diramare e sperimentare nuove funzionalità o progetti senza doversi preoccupare di rompere nulla.
• Come è stato menzionato in altre risposte, la capacità di commettere intenzionalmente il codice che si desidera condividere con gli altri è sostanzialmente diversa rispetto al salvataggio di tutte le versioni del codice a intervalli di 15 minuti. Stai senza dubbio salvando più versioni non funzionanti del codice che tu o altri vorrete in seguito scavare per trovare la versione precedente che avete effettivamente bisogno.

È abbastanza semplice avere un sistema di controllo della versione attivo e funzionante, particolare in un ambiente tanto semplice come questo. Quindi l'investimento richiesto non è molto alto. Come ho già detto, il sistema di backup che hai ora sembra che potrebbe essere inutilmente complesso e potenzialmente fragile. Dovresti trarre beneficio dagli anni di investimenti che la community ha compiuto nella creazione di strumenti come SVN, Git o Mercurial per risolvere esattamente il problema del mantenimento di più versioni del software e fornire una buona quantità di funzionalità aggiuntive che è direttamente utile per gli sviluppatori.

Impostando e usando il controllo della versione formale, svilupperai una serie preziosa di abilità che ti saranno utili per tutta la tua carriera. Quasi tutti gli ambienti di sviluppo software professionali utilizzano un sistema di controllo della versione. Conoscere i dettagli di come configurare e utilizzare un repository ti aiuterà di nuovo.

Non ho familiarità con Mercurial, ma da quello che ho capito, è un sistema di controllo di revisione in piena regola. Se hai già familiarità con esso, potrebbe valere la pena iniziare a sperimentarlo come VCS.

In un ambiente professionale in cui è presente il codice scritto dovresti sempre avere il controllo del codice sorgente.

C'è sempre il pericolo che un candidato intervista chieda cosa usi per il controllo della versione e rifiuta la posizione a causa della mancanza di un ragionevole sistema di controllo della versione.

Inoltre ... se sei in grado di assumere un professionista, potrebbero anche avere molto più difficile comprensione e utilizzo del tuo attuale ambiente di versioning.

Come altre persone hanno detto, "ora" è sempre un buon momento per iniziare a utilizzare il controllo della versione. Ci sono così tanti vantaggi nell'usare un buon sistema di controllo delle versioni che è quasi un gioco da ragazzi.

Hai detto di usare Mercurial. Come gli altri vcs distribuiti, puoi sempre inizializzare il tuo repository (privato) e lavorare lì. Perché non provarlo? Se inizia a funzionare per te, potrebbe funzionare per la tua squadra. DVCS è tutto basato sulla costruzione da zero.

Il controllo della versione è davvero uno dei pezzi più critici di un team di sviluppo funzionale. A parte il punto di vista sul fatto che il tuo codice è sempre sottoposto a backup, sei esposto a funzionalità come i messaggi di commit che ti aiutano a capire esattamente ciò che la persona prima di te (o tu stesso) ha fatto a un determinato file. Puoi anche diffare file con versioni precedenti e creare tag per versioni particolari. I tag sono un enorme vantaggio in quanto puoi praticamente creare un'istantanea della versione x.x.x del codice sorgente della tua app. Questo rende molto più facile rintracciare vecchi bug.

Inizia a leggere su piattaforme diverse e scopri cosa ti soddisfa meglio. Abbiamo usato SVN perché c'erano strumenti integrati nel nostro IDE per sfruttare SVN. Ironicamente non usiamo nemmeno questi strumenti ora, usiamo Tortoise SVN solo per il check-in e il check-out del codice.

Per rispondere alla tua domanda, è necessario il controllo della versione dal momento in cui scrivi la prima riga di codice.