Nel controllo della versione centralizzata, è sempre opportuno aggiornarlo spesso?

Personalmente, aggiorno quotidianamente le mie versioni locali.

Nello scenario che descrivi, farei il miglio supplementare

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

In questo modo

• Puoi effettuare il check-in tutti i giorni per conservare il codice sul server
• Non devi preoccuparti di rompere la build effettuando il check-in.
• Puoi utilizzare il repository per annullare alcuni lavori o diff quando necessario con i check-in precedenti.
• Lavorerai sicuramente sull'ultima base di codice e rilevi i possibili cambiamenti di codice in conflitto nella fase iniziale.

Gli svantaggi mentre li vedo sono

• L'unione dalla parte principale deve essere eseguita manualmente (o tramite script)
• Ci vuole più "amministrazione"

Sì, è una buona idea aggiornare spesso. Si aggiorna spesso per evitare conflitti di fusione difficili e questa è la base delle conoscenze SCM (Software Configuration Management) con il problema delle modifiche divergenti.

Ciò è indipendente se è centralizzato o distribuito; più tempo diverge da una fonte upstream (cioè se si tratta di un tronco, ramo o altro repository nel caso DVCS) maggiore è la possibilità di unire conflitti. Sì, durante l'aggiornamento potrebbero venire delle brutte sorprese dalla tua squadra, ma rimandare la brutta sorpresa è ancora peggiore (più a lungo aspetti, meno persone ricordano perché sono state apportate modifiche).

Perché l'aggiornamento funzioni, significa anche che tu e altri programmatori che lavorano sul codice non dovresti mai impegnare o spingere consapevolmente codice upstream che interrompe la build . Questo è solitamente il motivo per cui i programmatori si ramificano (o divergono dai termini upstream in SCM), per proteggere i membri del team e le altre parti interessate dall'avere un codice non funzionante, nel caso in cui una simile situazione dovesse inevitabilmente insorgere.

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

Il terzo punto elenco nella domanda è semplicemente sbagliato :

• You are working on a new feature which will surely take several days to complete, and you won't be able to commit before that because it would break the build.

Se conosci lavorerai su qualcosa che non puoi impegnare per un po 'di tempo, questo è l'esempio da manuale per l'utilizzo dei rami.

Non metterti nella situazione in cui hai molte modifiche in sospeso. Se conosci non sarai in grado di impegnarti nel ramo principale del tuo progetto per un po 'di tempo, quindi lavorerai su un altro ramo. E lì, commit spesso .

Se ti trovi già nella situazione descritta nella domanda, passa a un ramo adesso , conferma le modifiche e continua a lavorare in quel ramo.

Normalmente in CVCS è una buona idea aggiornare spesso. Ma se stai lavorando su una succursale, la domanda "aggiorna spesso o meno" diventa "unione spesso o no". E la risposta è sì comunque. Assicurati di impegnare tutte le modifiche in sospeso (nel ramo) prima di unire da un altro ramo, alla tua opzione di ripristinare l'unione in sicurezza, se necessario.

Penso che dovresti impegnarti più spesso. Se lavori per un lungo periodo come pochi giorni, dovresti suddividere il tuo codice e lavorare nel tuo ramo piuttosto che lavorare direttamente nel bagagliaio. So che è comodo iniziare a lavorare senza rami, ma non è molto flessibile in quanto non si può essere sicuri che il tuo aggiornamento / commit possa violare il tuo codice o meno, il che finisce con la situazione in cui manterrai il tuo aggiornamento / commit finché non avrai fatto il tuo lavoro "Feature branching" è migliore nel modo in cui puoi sempre eseguire il commit del tuo codice e, una volta terminato, basta unirlo più tardi.

Nella strategia di ramificazione, l'aggiornamento viene sostituito con l'unione dal tronco. Dalla mia esperienza, non è necessario unire spesso dal trunk, poiché il codice in un periodo di cinque giorni non cambierà molto ed è più semplice risolvere il conflitto una volta terminato.

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

• Le modifiche locali vengono salvate prima dell'aggiornamento, quindi se faccio un errore nell'unione, posso sempre tornare indietro e rifarlo.
• Quando eseguo modifiche più grandi, posso salvare le parti che sono state completate. Ciò semplifica la revisione delle rimanenti modifiche in corso.
• Quando correggo un bug durante un lavoro più grande, posso commettere solo quella correzione, impegnare temporaneamente il resto e "dcommit" la correzione a subversion mantenendo gli altri work in progress local.

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

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

In questo modo puoi creare il framework (interfaccia esterna, oltre alle funzioni di stub) e commetterlo, quindi ci dovrebbero essere minimi effetti di terze parti, mentre hai finito il resto del tuo sviluppo?

Nella situazione che descrivi, ritengo sia meglio avere file sorgente più piccoli di quelli meno numerosi.

In che modo è diverso per un controllo di versione centralizzato 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 fusione dal repository centrale al tuo posto di lavoro (e il tuo ramo di progetto è il tuo posto di lavoro).

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

A proposito, non so come si chiama "break the build". Tendo a lavorare in incrementi relativamente piccoli, in modo da mantenere uno stato compilabile, anche se interrompe alcune funzionalità. E faccio i test in modo che io sappia che l'unione non ha infranto qualcosa che dovrebbe funzionare. Di nuovo, è più facile risolvere un problema quando viene rilevato in anticipo.

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

Ho lavorato con i sistemi di controllo delle versioni che sono molto difficili da eseguire dopo l'aggiornamento. Su questi, tendo ad aggiornare solo appena prima di dover effettuare il check-in. Con sistemi di controllo delle versioni migliori, non c'è motivo di non aggiornarli più volte al giorno.