Todos os sistemas de controlo de versões têm de resolver um problema fundamental: como irá o sistema permitir aos utilizadores partilhar informação, evitando ao mesmo tempo que pisem, por acidente, os pés uns dos outros? É muito fácil os utilizadores escreverem acidentalmente por cima das alterações de outros utilizadores no repositório.
Considera o seguinte cenário: supõem que temos dois colegas, Harry e Sally. Cada um decide editar o mesmo ficheiro do repositório, ao mesmo tempo. Se o Harry guardar primeiro as suas alterações no repositório, é possível que (momentos depois) a Sally possa as substituir com a sua versão do ficheiro. Enquanto que a versão do Harry não se perderá definitivamente (porque o sistema recorda-se de cada alteração), qualquer alteração feita pelo Harry não estará presente na nova versão do ficheiro da Sally porque, para começar, ela nunca viu as alterações do Harry. O trabalho do Harry estará efectivamente perdido - ou pelo menos ausente da última versão do ficheiro - e provavelmente por acidente. Esta é definitivamente uma situação que queremos evitar!
Muitos sistemas de controlo de versões usam o modelo bloquear-modificar-desbloquear para resolver este problema, o que é uma solução muito simples. Em tal sistema, o repositório apenas permite que uma pessoa de cada vez possa modificar um ficheiro. Primeiro o Harry tem de bloquear o ficheiro, antes de poder editar o ficheiro. Bloquear um ficheiro é um pouco como requisitar um livro da biblioteca; se o Harry tem o ficheiro bloqueado, então a Sally não pode efectuar alterações nele. Se eia tentar bloquear o ficheiro, o repositório ir-lhe-á negar o pedido. Tudo o que ela pode fazer é apenas ler o ficheiro, e esperar que o Harry termine as suas alterações e liberte o bloqueio. Após o Harry desbloquear o ficheiro, termina a sua vez, e agora a Sally pode ter a sua vez ao bloquear e editar o ficheiro.
O problema com o modelo bloquear-modificar-desbloquear é que é um pouco restritivo, e torna-se muitas vezes um bloqueio para os utilizadores:
Bloquear pode causar problemas administrativos. Por vezes o Harry irá bloquear um ficheiro e esquecer-se disso. Enquanto, porque a Sally está ainda à espera para editar o ficheiro, tem as mãos atadas. Então o Harry vai de férias. Agora a Sally tem de se dirigir ao administrador para este libertar o bloqueio do Harry. A situação acaba por causar um grande e desnecessário atraso e tempo perdido.
Bloquear pode causar serialização desnecessária. E se o Harry estiver a editar o início de um ficheiro de texto, e a Sally simplesmente quiser editar o final do mesmo ficheiro? Essas alterações não se sobreporiam de todo. Eles poderiam facilmente editar o ficheiro simultaneamente, e nenhum grande mal adviria daí, assumindo que as alterações seriam propriamente integradas em conjunto. Não há nenhuma necessidade deles recorrerem a turnos nesta situação.
Bloquear pode criar um falso sentido de segurança. Imagina que o Harry bloqueia e edita o ficheiro A, enquanto a Sally simultaneamente bloqueia e edita o ficheiro B. Mas supõem que A e B dependem um do outro, e as alterações feitas a cada um deles são semanticamente incompatíveis. De repente A e B já não funcionam juntos. O sistema de bloqueio foi impotente na prevenção deste problema - mas no entanto forneceu um falso sentimento de segurança. É fácil para o Harry e para a Sally imaginar que ao bloquear os ficheiros, cada um estará a iniciar uma tarefa segura e isolada, o que por sua vez os inibe de discutir de antemão as suas alterações incompatíveis.
Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.
Eis um exemplo. Digamos que o Harry e a Sally criaram cada um, cópias de trabalho do mesmo projecto, copiadas do repositório. Eles trabalharão concorrentemente e efectuaram alterações no mesmo ficheiro A, em suas cópias. A Sally guarda as suas alterações no repositório, primeiro. Então o Harry tenta guardar as suas alterações mais tarde o repositório informa-o que o seu ficheiro A está desactualizado. Noutras palavras, o ficheiro A do repositório foi de algum modo alterado desde a última vez que o copiaste. Então o Harry pede ao seu cliente para integrar quaisquer novas alterações do repositório na sua cópia de trabalho do ficheiro A. Há probabilidades que as alterações da Sally não se sobreponham com as suas; pelo que uma vez que ambos os conjuntos de alterações estejam integrados, ele guardará a sua cópia de trabalho de volta para o repositório.
Mas se as alterações da Sally se sobrepuserem as do Harry? E depois? Esta situação é chamada de conflito, e não é normalmente um grande problema. Quando o Harry pede ao seu cliente para integrar as últimas alterações do repositório para a sua cópia de trabalho, a sua cópia do ficheiro A e de alguma maneira sinalizada como estando em conflito: poderemos observar ambos os conjuntos de alterações, e escolher manualmente entre elas. Ter em atenção que o software não pode resolver automaticamente os conflitos: só os humanos são capazes de compreender e efectuar as necessárias escolhas inteligentes. Uma vez que o Harry tenha resolvido manualmente a sobreposição das alterações (talvez ao discutir o conflito com a Sally), ele pode salvaguardar com segurança o ficheiro integrado de volta para o repositório.
O modelo copiar-modificar-integrar pode soar um pouco caótico, mas na prática funciona de um modo muito fluido. Os utilizadores podem trabalhar em paralelo, nunca esperando uns pelos outros. Quando trabalham nos mesmos ficheiros, acontece que a, a maior parte das suas alterações concorrentes não se sobrepõem; conflitos são raros. E a quantidade de tempo levada a resolver conflitos é muito inferior ao tempo perdido com o sistema de bloqueio
No final tudo se resume a um factor critico: comunicação com o utilizador. Quando os utilizadores não comunicam bem, aumentam os conflitos sintácticos e semânticos. Nenhum sistema pode forçar os utilizadores a comunicar na perfeição, e nenhum sistema pode detectar conflitos semânticos. Portanto não existe vantagens em ser iludido por uma falsa promessa de que o sistema de bloqueio irá evitar conflitos; na prática os sistemas bloqueantes parecem inibir mais a produtividade que qualquer outra coisa.
Existe uma situação particular onde o modelo bloquear-modificar-desbloquear funciona melhor, que é quando tens ficheiros não integráveis. Por exemplo, se o teu repositório contém algumas imagens, e duas pessoas alteram a imagem ao mesmo tempo, não existe forma de integrar essas alterações. Ou o Harry ou a Sally irão perder as suas alterações.
O Subversion usa por defeito a solução copiar-modificar-integrar, e em muitos casos, isto será tudo o que alguma vez irás precisar. No entanto, tal como na versão 1.2, o Subversion também suporta o bloqueio de ficheiros, pelo que se tiveres ficheiros não integráveis, ou simplesmente, fores forçado pela administração a usar uma política de bloqueio, o Subversion poderá ainda te fornecer as funcionalidades de que necessitas.