Nel controllo centralizzato della versione, è sempre bene aggiornarlo spesso?

Supponendo che:

• Il tuo team sta utilizzando il controllo centralizzato della versione.
• Stai lavorando a una funzionalità più ampia che richiederà alcuni giorni per essere completata e non potrai impegnarti prima perché interromperà la creazione.
• I membri del tuo team commettono ogni giorno qualcosa che potrebbe cambiare alcuni dei file su cui stai lavorando.

Poiché si tratta di un controllo centralizzato della versione, dovrai aggiornare il tuo checkout locale ad almeno un certo punto: almeno una volta prima di eseguire il commit della nuova funzionalità.

Se esegui l'aggiornamento solo una volta prima del commit, potrebbero esserci molti conflitti a causa delle molte altre modifiche dei tuoi compagni di squadra, che potrebbero essere un mondo di dolore da risolvere tutto in una volta.

Oppure, potresti aggiornare spesso, e anche se ci sono alcuni conflitti da risolvere giorno dopo giorno, dovrebbe essere più facile da fare, a poco a poco.

Rimarrebbe sempre una buona idea aggiornare spesso?

Personalmente, aggiorno quotidianamente le mie versioni locali.

Nello scenario che descrivi, farei il possibile

• Creazione di un ramo per la nuova funzionalità lunga.
• Unisci spesso dalla linea principale a questa nuova filiale.

Per di qua,

• Puoi effettuare il check-in ogni giorno per conservare il tuo codice sul server
• Non devi preoccuparti di interrompere la build effettuando il check-in.
• È possibile utilizzare il repository per annullare alcuni lavori o differenze, se necessario, con check-in precedenti.
• Sei certo di lavorare con la base di codice più recente e di rilevare tempestivamente eventuali modifiche al codice in conflitto.

Gli svantaggi come li vedo sono

• La fusione dalla rete principale deve essere eseguita manualmente (o tramite script)
• Ci vuole più "amministrazione"

Sì, è una buona idea aggiornarlo spesso. Si aggiorna spesso per evitare difficili conflitti di unione e questa è la base della conoscenza di Software Configuration Management (SCM) con il problema di cambiamenti divergenti.

Questo indipendentemente dal fatto che sia centralizzato o distribuito; maggiore è il tempo in cui divergi da una sorgente upstream (ovvero se si tratta di un trunk, branch o altro repository nel caso DVCS) maggiore è la possibilità di unire conflitti. Sì, durante l'aggiornamento possono presentarsi brutte sorprese dalla tua squadra, ma rinviare la brutta sorpresa è ancora peggiore (più a lungo aspetti, meno persone ricordano perché sono state apportate una serie di modifiche).

Affinché l'aggiornamento funzioni, ciò significa anche che tu e altri programmatori che lavorano sul codice non dovreste mai eseguire il commit o il push consapevole del codice upstream che interrompe la generazione . Questo è di solito il motivo per cui i programmatori si ramificano (o divergono dall'upstream in termini di SCM), per proteggere i membri del team e le altre parti interessate dall'eventuale violazione del codice qualora dovesse verificarsi inevitabilmente una situazione del genere.

Il mantra che puoi usare per ricordare è questo: "aggiorna, aggiorna, aggiorna, commetti". Assicurati sempre che le tue modifiche funzionino con gli altri prima di impegnarti. Questo serve anche per assicurarsi che il check out del codice funzioni anche per la prima volta.

Il terzo punto elenco nella domanda è semplicemente sbagliato :

• Stai lavorando a una nuova funzionalità che richiederà sicuramente diversi giorni per essere completata, e non sarai in grado di impegnarti prima perché interromperà la creazione.

Se sai che stai lavorando a qualcosa che non puoi impegnare per un po 'di tempo, questo è l'esempio del libro di testo per l'uso dei rami.

Non metterti nella situazione in cui hai molte modifiche in sospeso. Se sai che non sarai in grado di impegnarti nel ramo principale del tuo progetto per qualche tempo, quindi lavora su un altro ramo. E lì, commetti spesso .

Se sei già nella situazione descritta nella questione, quindi passare a una filiale in questo momento , confermare le modifiche e continuare a lavorare in quel ramo.

Normalmente in CVCS è una buona idea aggiornarlo spesso. Ma se stai lavorando su un ramo, allora la domanda "aggiorna spesso o no" diventa "unisci spesso o no". E la risposta è sì comunque. Assicurati di eseguire il commit di tutte le modifiche in sospeso (nel ramo) prima di unirti a un altro ramo, nella tua opzione per ripristinare l'unione in modo sicuro, se necessario.

Penso che dovresti impegnarti più spesso. Se hai intenzione di lavorare a lungo come pochi giorni, dovresti ramificare il tuo codice e lavorare nel tuo ramo piuttosto che lavorare direttamente nel trunk. So che è conveniente iniziare a lavorare senza filiali, ma non è molto flessibile in quanto non si può essere sicuri che l'aggiornamento / commit possa interrompere il codice o meno, il che finisce per la situazione in cui si terrà l'aggiornamento / commit fino a quando non si fatto il tuo lavoro. "Branching delle funzionalità" è migliore nel modo in cui è sempre possibile eseguire il commit del codice e ricollegarlo più tardi al termine.

Nella strategia di diramazione, l'aggiornamento viene sostituito dall'unione dal trunk. Dalla mia esperienza, non è necessario fondersi così spesso dal trunk, poiché il codice in circa cinque giorni non cambierebbe molto ed è più facile risolvere il conflitto solo una volta finito.

In realtà trovo più conveniente usare un controllo di versione distribuito localmente. Cioè, uso git come client di sovversione. Questo ha i vantaggi che:

• Le modifiche locali vengono salvate prima dell'aggiornamento, quindi se commetto un errore nell'unione, posso sempre tornare indietro e farlo di nuovo.
• Quando faccio grandi cambiamenti, posso salvare le parti che sono finite. Ciò semplifica la revisione delle rimanenti modifiche in corso.
• Quando correggo un bug durante alcuni lavori più grandi, posso commettere solo quella correzione, commettere temporaneamente il resto e "annullare il commit" della correzione in sovversione mantenendo gli altri lavori in corso locali.

Se stai aggiungendo una nuova funzionalità, potresti creare un nuovo file sorgente singolo (e un corrispondente file di intestazione dell'interfaccia esterna)?

Sono preoccupato che una "nuova funzionalità" abbia implicazioni diffuse? L'orientamento agli oggetti potrebbe non essere più la parola d'ordine di una volta, ma in questo paradigma c'è un merito.

In questo modo potresti creare il framework (interfaccia esterna, oltre a funzioni stub) e impegnarti che allora dovrebbero esserci effetti minimi di terze parti, mentre finisci il resto del tuo sviluppo?

Nella situazione che descrivi ritengo sia meglio avere file sorgente più piccoli rispetto a un numero inferiore di file più grandi.

In che modo differisce per un controllo centralizzato della versione rispetto a uno distribuito?

In entrambi i casi dovrai effettuare il check-in in un luogo il cui contenuto sarà spostato rispetto a quello che hai iniziato. Non vedo alcuna differenza nella frequenza di unione dal repository centrale al luogo di lavoro (e il ramo del progetto è il luogo di lavoro).

Tendo ad essere per l'unione spesso (almeno una volta al giorno, potrei anche unirmi in qualche altro momento conveniente per me, o quando so che qualcuno ha registrato qualcosa che ha un impatto su ciò su cui sto lavorando). È molto più facile assorbire le piccole modifiche e se si riscontra un problema, le persone sono più utili quando si chiede loro cosa hanno appena effettuato il check-in rispetto a quello che hanno effettuato il check-in una settimana fa.

A proposito, non so come si chiama "rompi la build". Tendo a lavorare con incrementi relativamente piccoli, in modo da mantenere uno stato compilabile, anche se interrompe alcune funzionalità. E eseguo i test in modo da sapere che l'unione non ha rotto qualcosa che dovrebbe funzionare. Ancora una volta, è più facile risolvere un problema quando viene rilevato in anticipo.

Dipende da quanto sei bravo a "non aggiornare" quando qualcun altro rompe la build. Da un lato, si desidera aggiornare il più piccolo possibile. Personalmente, aggiorno quasi ogni volta che noto che sono disponibili aggiornamenti. D'altra parte, se la build si interrompe e ci vorrà un giorno perché qualcun altro lo risolva, nel frattempo vuoi comunque essere in grado di lavorare sulla tua nuova funzionalità.

Ho lavorato con sistemi di controllo della versione di cui è molto difficile eseguire il backup dopo l'aggiornamento. Su quelli, tendo ad aggiornare solo poco prima di dover effettuare il check-in. Con i migliori sistemi di controllo della versione, ci sono pochi motivi per non aggiornare più volte al giorno.