То, что я говорю ниже, действительно для svn, потому что git или mercurial немного отличаются (я бы сказал, проще).
1) Человек B должен обновить и объединить изменения в своей собственной локальной копии до коммит -ing (он также может просто проверить если есть изменения). Если он просто попытается зафиксировать , она получит сообщение о том, что его локальная копия svn устарела.
2) Лицо B находится в некотором затруднении, так как слияние не будет легким (оно не будет автоматически управляться SVN, оно будет конфликтовать ) ... если это действительно слишком сложно, B придется думаю, что она снова меняется.
Эта проблема на самом деле не имеет решения. Некоторые системы управления версиями допускают какую-то блокировку, но это порождает другие проблемы (файл может оставаться заблокированным в течение длительного времени, и никто, кроме блокировщика, не может работать с ним в промежутке, даже если изменения легко слились). Просто внесите небольшие изменения и поговорите с другими программистами (реальным собранием, IRC, электронной почтой или любым другим способом), чтобы избежать этого.
3) Ветвление действительно полезно с распределенной системой контроля версий. Он существует в SVN в искалеченной версии. Просто вы делаете копию текущего каталога текущего репо в другом каталоге, каждый из двух каталогов развивается со своим собственным жизненным циклом (скажем, один заморожен только для исправлений ошибок, а другой - для новых функций и эволюций), и в какой-то момент вы пытаетесь объединить изменения между двумя репозиториями, например, попытаться портировать исправление в новую ветку функций или перенести новую функцию в новую ветку старой.