Сви системи контроле верзија имају да реше исте основне проблеме: како ће систем омогућити корисницима да деле информације, али да их спречи да нехотично корачају стопама једни других? Веома је лако да једни другима корисници инцидентно препишу промене у спремишту.
Замислимо овај сценарио: претпоставимо да имамо два сарадника, Хари и Сали. Сваки одлучи да уреди исти фајл из спремишта у исто време. Ако Хари први сачува своје измене у спремиште, тада је могуће (неколико тренутака касније) да их Сали нехотице препише својом новом верзијом фајла. Пошто Харијева верзија фајла неће бити изгубљена заувек (јер систем памти све промене), све промене које је урадио Хари неће бити присутне у Салиној новој верзији фајла, јер она није видела Харијеве измене на почетку рада. Харијев рад је ефективно изгубљен - или у најмањем недостаје у задњој верзији фајла - и вероватно мимо плана. Ово је дефинтивно ситуација коју желимо да избегнемо.
Многи системи контроле верзија користе закључај-измени-откључај модел да означе овај проблем, што је веома једноставно решење. У таквим системима, спремиште дозвољава само једној особи да мења фајл у исто време. Прво Хари мора закључати фајл пре него што може да га мења. Закључавање фајла је много слично позајмљивању књиге из библиотеке; ако Хари има закључани фајл, онда Сали не може да направи било какву измену на њему. Ако она покуша да закључа фајл спремиште ће забранити захтев. Све што може урадити је да чита фајл и чека да Хари заврши своје измене и откључа фајл. Када Хари откључа фајл, он га враћа и Сали га може узети закључавањем и да га уређује.
Проблем са закључај-измени-откључај моделом је да је помало рестриктив и често постаје препрека за кориснике:
Закључавање може да направи административни проблем. Понекад Хари ће закључати фајл и заборавити на њега. Међутим, пошто Сали још чека да уреди фајл, њене руке се везане. И онда Хари одлази на одмор. Сада Сали има да добије од Администратора ослобађање Харијевог закључавања. Ситуација се завршава узрокујући пуно непотребног кашњења и изгубљеног времена.
Закључавање може да проузрокује нежељену серијализацију. Шта ако Хари уређује почетак текст фајла, а Сали једноставно жели да уреди крај истог фајла? Ове измене се уопште не преклапају. Они могу лако да уређују фајл истовремено, неће доћи до велике штете, узевши да се измене одговарајуће уједине. Њима није потребно да се окрену од овакве ситуације.
Закључавање може да створи лажни осећај сигурности. Узмимо да Хари закључа и уређује фајл А, док Сали истовремено закључа и уређује фајл Б. Претпоставимо да А и Б зависе један од другог и да измене урађене на било коме семантички нису компатибилне. Изненада А и Б не раде више заједно. Закључавајући систем нема снаге да предупреди проблем - чак некако даје осећај лажне сигурности. Лако је да Хари и Сали замисле то закључавањем фајлова, свако почиње сигуран, издвојен задатак и то га спречава да разматра некомпатибилне измене учињене раније.
Субверзија, ЦВС и други ситми контроле верзија користе копирај-измени-стопи модел као алтернативу закључавању. У овом моделу сваки кориснички клијент чита спремиште и креира сопствену радну копију фајла или пројекта. Корисник онда ради паралелно мењајући своју приватну копију. На крају, приватна копија се стопи у нову финалну верзију. Систем контроле верзија често је помогнут стапањем али извршно је човек одговоран да се то уради коректно.
Ево примера. Рецимо да Хари и Сали креирају радне копије истог пројекта, копирањем из спремишта. Они раде истовремено, и праве измене на истом фајлу А у оквиру својих копија. Сали сачува своје измене у спремиште прва. Када Хари покуша да сачува своје измене касније, спремиште га информише да је његов фајл А застарео. Другим речима, фајл А у спремишту има нечије измене од задњег копирања. Тако Хари пита свог клијента да стопи било које нове измене из спремишта у његову радну копију фајла А. Постоји шанса да Салине измене не прекривају његове; тако да ће имати оба скупа измена интегрисано, он сачува своју радну копију назад у спремиште.
Али шта ако Салине измене прекривају Харијеве измене? Шта тада? Ова ситуација се зове конфликт, и то обично није велики проблем. Када Хари тражи од свог клијента да стопи задње измене у спремишту у његову радну копију, његова копија фајла А је некако означена да је у стању конфликта: он ће бити у могућности да види оба скупа конфликтних измена, и ручно да изабере између њих. Приметимо да софтвер не може аутоматски да реши конфликт; само људи су способни да разумеју и ураде неопходне интелигентне изборе. Једном кад Хари ручно реши преклапање измена (можда дискусијом конфликта са Сали!), он може безбедно да сачува стопљен фајл назад у спремиште.
Копирај-мењај-стопи модел може да звучи помало хаотично, али у пракси, ради екстремно глатко. Корисници могу да раде паралелно, никада не чекају један другог. Када раде на истим фајловима искључено је да њихове истовремене измене не буду уписане; конфликти су ретки. И износ времена узет за решавање конфликта је мањи од времена изгубљеног закључавањем система.
На крају, све долази у један критичан фактор: корисничка комуникација. Када је лоша комуникација између корисника синтаксни и семантички конфликти расту. Нема система који ће натерати кориснике да комуницирају перфектно, и нема система који може да детектује семантички конфликт. Тако да није поента да се буде умирен лажним обећањем да систем закључавања некако предупређује конфликт; у пракси, закључавање изгледа спречава више продуктивност него било шта друго.
Постоји једна обична ситуација где је закључај-мењај-откључај модел бољи, и то где имате нестопиве фајлове. На пример ако ваше спремиште садржи неке графичке слике, и два човека мењају слике у исто време, нема начина да се те измене споје заједно. Или Хари или Сали ће изгубити своје измене.
Субверзија користи копирај-измени-стопи решење подразумевано, и у многим случајевима ово је све што вам је потребно. Међутим, од Верзије 1.2 Субверзија такође подржава закључавање фајлова, тако да ако имате нестопиве фајлове, или ако једноставно форсирате политику закључавања преко управе, Субверзија ће још омогућавати жељене особине.