Alle versiebeheersystemen moeten hetzelfde fundamentele probleem oplossen: hoe zorgt een systeem ervoor dat gebruikers informatie kunnen delen, maar voorkomt dat ze per ongeluk op elkaars voeten gaan staan? Het is maar al te gemakkelijk voor gebruikers om per ongeluk elkaars wijzigingen te overschrijven in het archief.
Beschouw het volgende scenario: stel we hebben twee collega's, Harry en Sally. Ze besluiten beide om hetzelfde archief te wijzigen op hetzelfde moment. Als Harry de wijzigingen als eerste in het archief opslaat, dan is het mogelijk dat Sally (enkele ogenblikken later) per ongeluk zijn wijzigingen overschrijft met haar nieuwe versie van het bestand. Alhoewel Harry's wijzigingen niet voor goed verloren zijn (omdat het systeem elke wijziging onthoudt), zijn de wijzigingen die Harry aanbracht niet zichtbaar in Sally's nieuwe versie van het bestand, omdat zij Harry's wijzigingen helemaal niet eens gezien heeft. Harry's werk is dus in feite verloren - of ontbreekt in elk geval in de laatste versie van het bestand - en waarschijnlijk ook nog per ongeluk. Dit is precies de situatie die we willen voorkomen!
Veel versiebeheersystemen gebruiken een blokkeren-wijzigen-blokkade opheffen model om dit probleem te adresseren, hetgeen een zeer simpele oplossing is. In zo'n systeem staat het archief maar aan één persoon tegelijkertijd toe om een bestand te wijzigen op één bepaald moment. Eerst moet Harry het bestand blokkeren, voordat hij kan beginnen om het bestand te wijzigen. Blokkeren van een bestand lijkt op het lenen van een boek bij de bibliotheek; als Harry het bestand heeft geblokkeerd, kan Sally geen wijzigingen hierin aanbrengen. Als zij probeert het bestand te blokkeren, zal het archief dit verzoek weigeren. Ze kan alleen het bestand bekijken en wachten tot Harry klaar is met zijn wijzigingen en de blokkade opheft. Nadat Harry de blokkade op het bestand heeft opgeheven, is zijn beurt voorbij en is Sally aan de beurt om het bestand te blokkeren en te wijzigen.
Het probleem met "blokkeren-wijzigen-blokkade opheffen" is dat het erg beperkend is en vaak voor gebruikers een wegversperring wordt.
Blokkeren kan administratieve problemen veroorzaken. Soms zal het gebeuren dat Harry een bestand blokkeert en dat daarna vergeet. In de tussentijd kan Sally niets doen, omdat ze aan het wachten is om het bestand te mogen wijzigen. En als Harry dan ook nog op vakantie gaat, moet Sally een beheerder vragen om Harry's blokkade op te heffen. Deze situatie veroorzaakt veel onnodige vetraging en verloren tijd.
Blokkeren kan onnodige serializatie veroorzaken. Stel dat Harry aan het begin van een bestand iets wil wijzigen en Sally aan het einde van datzelfde bestand. Deze wijzigingen overlappen elkaar niet. Ze zouden gemakkelijk tegelijkertijd het bestand kunnen wijzigen, waarbij geen grote schade zal ontstaan, ervanuitgaande dat de wijzigingen netjes samengevoegd worden. Er is geen reden om op elkaars beurt te wachten.
Blokkeren kan een vals gevoel van veiligheid geven. Stel dat Harry bestand A blokkeert en wijzigt, terwijl Sally tegelijkertijd bestand B blokkeert en wijzigt. Maar wat als A en B van elkaar afhankelijk zijn, en de wijzigingen die gemaakt zijn, niet compatibel zijn? A en B zullen ineens niet meer samen kunnen werken. Het blokkeringssysteem was niet in staat om dit probleem te voorkomen - maar op de een of andere manier gaf het wel een vals gevoel van veiligheid. Het is voor de hand liggend dat Harry en Sally bedenken dat ze door het blokkeren van de bestanden, een veilige, geïsoleerde taak beginnen, wat ze ervan weerhoudt om hun incompatibele wijzigingen te bespreken.
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.
Zie hier een voorbeeld. Stel dat Harry en Sally elk een werkkopie hebben gemaakt vanaf het archief van hetzelfde project. Ze werken tegelijkertijd en wijzigen hetzelfde bestand A in hun werkkopie. Sally slaat haar wijzigingen als eerste in het archief op. Als Harry later probeert zijn wijzigingen op te slaan, informeert het archief hem dat het bestand A verouderd is. Met andere woorden, bestand A in het archief is op de een of andere manier in het archief gewijzigd sinds hij het bestand voor het laatst gekopieerd heeft. Harry zal nu zijn client vragen om de wijzigingen vanuit het archief met zijn werkkopie van bestand A samen te voegen. De kans is groot dat wijzigingen die Sally heeft gemaakt, niet overlappen met zijn eigen wijzigingen; dus zodra hij beide sets heeft geïntegreerd, kan hij zijn werkkopie in het archief opslaan.
Maar wat gebeurt er als Sally's wijzigingen wel overlappen met Harry's wijzigingen? Wat dan? Deze situatie wordt een conflict genoemd, en is meestal helemaal niet zo'n probleem. Als Harry zijn client vraagt om de wijzigingen in het archief samen te voegen met zijn werkkopie, wordt zijn kopie van bestand A gemarkeerd als zijnde in staat van conflict: hij zal beide sets van conflicterende wijzigingen kunnen bekijken en handmatig kiezen tussen de sets. Software kan niet automatisch conflicten oplossen; alleen mensen zijn in staat om te begrijpen en de juiste intelligente keuzes te maken. Zodra Harry handmatig de conflicten heeft opgelost (misschien wel door te overleggen met Sally), kan hij de wijzigingen in het samengevoegde bestand opslaan in het archief.
Het kopieren-wijzigen-samenvoegen model lijkt misschien wat chaotisch, maar in de praktijk werkt het zeer probleemloos. Gebruikers kunnen parallel werken, en hoeven nooit te wachten op elkaar. Als ze aan dezelfde bestanden werken, zal het in de meeste gevallen geen overlappende wijzigingen betreffen; Conflicten treden niet vaak op. En de tijd die het kost om een conflict op te lossen is veel minder dan de tijd die verloren gaat door het blokkeersysteem.
Uiteindelijk komt het allemaal aan op één kritieke factor: communicatie tussen de gebruikers. Als een gebruiker slecht communiceert, zullen zowel syntactische als semantische conflicten meer gaan optreden. Geen enkel systeem kan gebruikers dwingen om perfect te communiceren, en geen enkel systeem kan semantische conflicten detecteren. Het heeft dus geen enkele zin om in slaap gesust te worden door een blokkeersysteem dat zogenaamd conflicten kan voorkomen; in de praktijk lijkt het of blokkeren de productiviteit meer dan wat dan ook remt.
Er is één voorkomende situatie waar het blokkeren-wijzigen-vrijgeven model beter werkt, en dat is als je bestanden hebt, waarvan wijzigingen niet samenvoegbaar zijn. Als je archief bijvoorbeeld grafische bestanden bevat en twee mensen wijzigen een grafische bestand op hetzelfde moment, is er geen manier om deze wijzigingen samen te voegen. Ofwel de wijzigingen van Harry of die van Sally zullen verloren gaan.
Subversion gebruikt standaard de kopieer-wijzigen-samenvoegen methode, en in veel gevallen is dat alles wat je nodig hebt. Echter, vanaf versie 1.2, ondersteund Subversion ook het vergrendelen van bestanden. Als je niet samenvoegbare bestanden hebt, of als het management simpelweg het gebruik van de vergrendelwerkwijze oplegt, levert Subversion nog steeds de functionaliteit die je nodig hebt.