Perché evitare il blocco pessimistico in un sistema di controllo versione?

Question

Sulla base di alcuni post che ho letto sul controllo della versione, sembra che la gente pensi che il blocco pessimistico in un sistema di controllo della versione sia una cosa negativa. Perché? Comprendo che impedisce a uno sviluppatore di inviare una modifica mentre un altro ha estratto il file, ma che importa? Se i tuoi file di codice sono così grandi che hai costantemente più di una persona che ci lavora allo stesso tempo, invio che dovresti riorganizzare il tuo codice. Suddividilo in unità funzionali più piccole.

L'integrazione di modifiche simultanee al codice è un processo noioso e soggetto a errori anche con gli strumenti forniti da un buon sistema di controllo della versione per renderlo più semplice. Penso che dovrebbe essere evitato, se possibile. Quindi, perché il blocco pessimistico è scoraggiato?

Answer 1

Dipende dal tuo progetto e dal tuo team in generale. Il blocco pessimistico è buono perché è facile da capire: uno sviluppatore alla volta e nessuna fusione richiesta!

Tuttavia, la cosa brutta è che è esattamente questo: uno sviluppatore alla volta. In questo momento ho la situazione in cui un collega è andato sul posto e, prima di andarsene, ha controllato tutto in modo che se avesse dovuto correggere eventuali bug, avrebbe potuto tornare e controllare tutte le sue modifiche in ... ottimo per lui , schifoso per me e il resto del team di sviluppo alla base.

Se riesci a aggirare il blocco pessimistico nel tuo team, allora è bene usarlo, davvero, il motivo principale per cui le persone lo odiano è perché è la pratica predefinita di Visual SourceSafe. Se non sei sicuro di unire molte modifiche, allora hai un altro motivo per usarlo: se hai mai usato un SCM di blocco ottimistico e hai unito un'unione, saprai quanto è difficile recuperare.

Se riesci a gestire l'unione, il blocco ottimistico è superiore e lo consiglierei, ma non devi consegnare la tua carta geek se non vuoi usarla.

Answer 2

1. Gioca con Source Safe e fai partire uno sviluppatore per una vacanza di due settimane. Aggiungete a ciò gli amministratori VSS che non ci sono. Ora hai una correzione da pubblicare ma non puoi a causa dello sviluppatore
2. Se si stanno lavorando su più funzionalità e / o correzioni di bug. Non importa quanto sia piccolo il tuo codice, avrai comunque la contesa per un file centrale

Answer 3

1. Bob deve modificare FooBar.java
2. John l'ha verificato per la modifica
3. Bob modifica comunque la sua copia locale e la salva come FooBar.java.bak
4. Quando John fa il check-in, Bob lo controlla
5. Bob copia FooBar.java.bak su di esso e lo controlla in
6. John riesce a reimplementare il suo film

L'ho visto accadere più volte. Gli sviluppatori lo fanno perché questo processo è fastidioso:

1. Bob deve modificare FooBar.java
2. John l'ha verificato per la modifica
3. Bob deve aspettare agitando i pollici fino a quando John non ha finito

Il blocco pessimistico sembra l'ora amatoriale, scusa.

Answer 4

• Non sempre hai la possibilità di separare i file
  • File di configurazione
  • File XML
• Anche file relativamente piccoli possono ancora contenere parti distinte alle quali più di uno sviluppatore deve accedere
  • Biblioteche
  • Utilità
• Gli strumenti di fusione sono molto più intelligenti di quanto non siano mai stati
  • I conflitti sono piuttosto rari
• Riduce i ritardi dovuti agli sviluppatori che dispongono di file "accidentalmente" verificato

Answer 5

Se uno sviluppatore non è in grado di gestire l'unione e la risoluzione dei conflitti, dovrebbe essere rieducato.

È comune che anche i file di piccole dimensioni causino conflitti, ad esempio con i JSP una persona (sviluppatore web) potrebbe cambiare il codice del layout e qualcun altro potrebbe cambiare l'API per il modello utilizzato dal JSP.

Answer 6

Per quanto riguarda il caso con Bob e John, i sistemi cooperativi come svn non impediscono questo scenario più di quanto non faccia un sistema di blocco. Posso 'aggiornare' FooBar.java, che soddisfa svn che ho l'ultima edizione, quindi eliminare quel file localmente e sovrascriverlo con la mia copia personale che ho fatto senza alcun riguardo per la versione di base, e controllarlo, distruggendo felicemente cambia l'altro ragazzo. Nessun sistema, bloccando o meno, impedisce questo, quindi non vedo il punto di portarlo al dibattito.

Il vero problema è decidere quale sia il tuo equilibrio tra

probabilità di unire errori           vs. inconveniente causato da persone che bloccano i file

L'idea che un sistema di blocco o non di blocco sia "superiore" è una sciocchezza.

Ho usato VSS, nella sua modalità di blocco completo predefinita, con 6 sviluppatori, e ha funzionato come un sogno. Occasionalmente, qualcuno dimentica di rilasciare un lucchetto e dovremmo cacciarli o rompere il lucchetto manualmente e unire le mani quando tornano, ma questo era molto minimale. Ho visto svn rovinare la sua unione automatica più di una volta, in modo che non mi fidi davvero. Non segnala sempre un "conflitto" quando due persone hanno modificato lo stesso file in un modo che non può essere unito automaticamente.
Al contrario, ho visto le persone diventare impazienti con le serrature di VSS, modificare le proprie copie, e controllandoli sciatto sopra il codice degli altri popoli, e ho visto svn mi cattura facilmente quando potrei accidentalmente provare a controllare qualcosa che è stato modificato da qualcun altro dall'ultima volta che l'ho verificato.

Il mio punto è che questo non è un dibattito sensato da tenere. Il successo di entrambi i sistemi diminuisce al modo in cui gestisci i punti di conflitto quando si verificano, non se un sistema o l'altro è migliore.

Answer 7

Il blocco pessimistico è (esperienza personale) in termini di collaborazione. A volte viene facilmente sostituito da una buona comunicazione di squadra. Solo dicendo " Ehi, lavorerò su questi pochi file per un po '" ;.

Ho lavorato in team da 2 a 6 persone senza blocco e non abbiamo mai avuto problemi, al di là di alcune fusioni usuali e necessarie.

Una volta ho anche lavorato con il blocco di un progetto ospitato da Visual SourceSafe . Era controproducente per IMHO.

Answer 8

Gli sviluppatori di software sono sempre ottimisti: dai un'occhiata alle loro abilità di stima!

In pratica scopriamo che i conflitti sono rari e i vantaggi di non doversi preoccupare di bloccare superano la fase occasionale di risoluzione dei conflitti.

Answer 9

  

se i tuoi file di codice sono così grandi da avere costantemente più di una persona che ci lavora contemporaneamente

In questo caso è tempo che gli "esseri umani" prendano in carico e coordinino qualsiasi cambiamento. Nel caso ideale, e se la gestione del tuo progetto va bene, raramente colpirai un momento in cui stai provando a cambiare un file bloccato perché qualcuno avrà delle cose coordinate in modo che ciò non accada praticamente.

In altre parole, saprai che "Bob" sta apportando una grande serie di modifiche nei componenti X / Y / Z, se hai una correzione di bug nel componente X, saprai di parlare con Bob prima di provare a inviare il tuo modifiche.

Come ho detto questo è l'ideale;)

Answer 10

Il blocco pessimistico è una buona idea se saranno probabili gravi conflitti. Per la maggior parte della programmazione non vedrai alcun conflitto serio, quindi il blocco pessimistico è abbastanza inutile. Eccezioni a questo sarebbe se tu sei:

• Lavorare su file binari in cui non è davvero possibile unire le risorse artistiche (modelli, trame, ecc.) è un buon esempio.
• Lavorare con utenti non tecnici che non sanno come unirsi e non vogliono imparare (principalmente artisti, ma alcuni scrittori tecnici si daranno una pacca anche su questo).
• Lavorare su file molto grandi che non possono essere facilmente uniti o suddivisi in file più piccoli a causa dell'elevato grado di complessità (mai visto una situazione come quella di prima mano, ma sono sicuro che sia possibile).

In caso contrario ...