Sta usando Locking / Unlocking in Version Control e Anti-Pattern?

Is there any good reason for locking to be part of a version control system?

Sì, certo! Significa che non devi MAI preoccuparti di unire, il che è un problema serio in qualsiasi ambiente di controllo delle versioni.

Tuttavia, dall'esperienza amara è stato appreso che l'unico dolore più grande della fusione è essere costretti a bloccare il tuo team dallo sviluppo di un file finché non sei pronto a impegnare l'intero sviluppo. Ecco perché i moderni VCS, incluso TFS (e versioni successive di VSS, sebbene non sia stato attivato per impostazione predefinita), preferiscono rendere le unioni più semplici rendendole del tutto inutili, ad ogni costo.

Non è un anti-pattern perché non tutti possono lavorare con i file di testo. Come sottolinea questa persona , potresti utilizzare un'applicazione che crea file binari in un formato proprietario non documentato che non puoi facilmente unire in seguito.

Un caso più semplice di ciò sono le immagini, ha sempre senso solo che una persona lavori su di essa alla volta. Senza bloccare hai bisogno di una buona comunicazione di squadra in modo che tutti sappiano su cosa stanno lavorando gli altri ed evitare di calpestarsi l'un l'altro. La comunicazione è importante in ogni squadra, ma fare affidamento su di essa per evitare conflitti di lavoro può ridimensionare in modo scarso i team di grandi dimensioni.

Anche se fai riesci a lavorare con i file di testo, potrebbe essere ancora scomodo a causa del contesto (grazie a @mike). Ad esempio, dai un'occhiata a questa domanda: Git che si fonde all'interno di una linea , in particolare:

With a LaTeX document this is particularly annoying, as the common habit when writing LeTeX is to write a full paragraph per line and just let your text editor handle word wrapping when displaying for you.

C'è una soluzione praticabile proposta a questa domanda, ma quando lavori con i linguaggi umani, le cose spesso diventano complicate.

La maggior parte dei formati di file binari non può essere unita dal controllo del codice sorgente. Se viene modificato da due persone contemporaneamente, l'ultimo da controllare "vince". Il blocco può essere utile in quella situazione, anche se molti team usano altri mezzi di comunicazione (come l'assegnazione dei proprietari) per prevenire un simile problema.

Al di fuori dei file binari, la maggior parte delle persone concorda sul fatto che il blocco VCS è un anti-pattern, sebbene ovviamente abbia i suoi sostenitori. Spesso porta le persone a fare unioni al di fuori del controllo di versione, o a fare cambiamenti locali "solo per scopi di debug" in un file che qualcun altro ha bloccato, quindi trascurando di verificarlo. L'unione può essere fastidiosa, ma occuparsi di serrature è solitamente più fastidioso . Ecco perché la maggior parte dei VCS centralizzati oggigiorno ti permette di bloccare selettivamente determinati file e non altri.

Consiglio vivamente di leggere il controllo della versione con l'esempio: link Spiega molto chiaramente i concetti di vari sistemi, incluso quando il blocco funziona e quando non lo fa (che è davvero per i file non di testo e quando l'unione non può essere risolta.) Il vero blocco non è possibile (a causa dell'accesso offline ) ma una sorta di concetto di blocco può essere utile per evitare di sovrascrivere il lavoro di qualcun altro.

(Indica anche che puoi ancora usare un server centrale in un git-setup, e potrebbe aver senso farlo. Distributed non significa che uno dei repository non possa avere un significato speciale.)