Пожаробезопасность в системах управления версиями

На сегодняшний день существуют два типа систем управления версиями: клиент-серверный и распределенный. Но несмотря на огромное различие между ними мы все-равно продолжаем использовать центральный сервер для синхронизации работы между участниками команды.
А что будет если в один прекрасный день центральный сервер сгорит?
Давайте это обсудим

Клиент-серверная архитектура

В категорию данных систем управления версиями входят такие как CVS, SVN. При работе с такими системами у вас обязательно должен быть сервер на котором будет установлено специальное программное обеспечение для работы с версионированием. И каждый раз при получении обновлений исходного кода или фиксации изменений вы обращаетесь на этот центральный сервер. Если произойдет крах его, вы потеряете всю историю изменений, которую увы восстановить не получится. Это конечно можно решить бэкапами. В результате вы потеряете только ту часть которая была создана после создания последнего бэкапа.
В противоположность такой модели приверженцы распределенных систем управления версиями рекламируют их, указывая на то что им не требуется центральный сервер и что эта модель более защищена от проблем в случае краха центрального сервера.

Распределенная архитектура

Но вы когда-нибудь видели чтобы в командах где используется тот-же git или mercurial работали без центрального сервера? Я честно говоря ни разу. Но приверженцы DVCS все-таки правы. Когда вы получаете код из репозитория централного сервера, вы не только получаете последнюю версию, но также и историю изменений, в итоге к вам приходит весь репозиторий. Вы, в свою очередь, можете также выступать в виде центрального сервера для другого участника команды. Но если этот участник команды будет заливать свои изменения в ваш репозиторий, вам необходимо будет эти изменения проталкивать дальше на центральный сервер, для того чтобы все участники команды имели последний код. И что мы имеем? без центрального сервера не обойтись, но в случае краха его, восстановить историю и все остальное все-же получиться. И бэкапы не играют столь важную роль.

Равнораспределенная архитектура

А теперь подумайте если создать такую систему где не надо было бы держать сервер для синхронизации, но у всех участников команды всегда была бы актуальная версия кода. Эта система мне видеться в следующем виде: весь исходный код хранится у всех участников команды, но при этом когда один участник команды фиксирует свои изменения они передаются, к примеру, двум коллегам, а те в свою очередь еще двум и так до тех пор пока у всей команды не будет актуальная версия. С точки зрения отказоустойчивости эта система выглядит просто идеальной. Нет центрального сервера, нет вероятности что произойдет потеря данных при его крахе, также не потребуется тратить время на восстановление потерянных данных после краха сервера. Но в этой идее также имеются недостатки, а именно что если команда состоит из малого количества участников (1-2 человека), вероятность потери данных очень высока. Одно из решений данной проблемы может быть использование, все-таки, сервера. С другой-же стороны возможно, к примеру, распространение репозитория программы не только среди участников команды разрабатывающей данный продукт, а и среди прочих у которых установлена данная VCS. Конечно-же для прочих не имеющих отношение к разработки данного продукта код перед доставкой должен быть зашифрован.

Итак, с технической стороны, для работы системы должен быть установлен сервис в операционной системе который бы принимал изменения от коллег, заливал бы в локальный репозиторий и перенаправлял полученные данные дальше, другим участникам команды. Когда разработчику надо обновиться он будет получать код из локального репозитория.
Механизм фиксации изменений в данном случае получается следующий: разработчик выполняет команду по фиксации изменений, эти изменения попадают в первую очередь в локальный репозиторий, а сервис из этого репозитория получает и распростроняет среди команды.
Ну идея вроде бы довольно простая. И добавить вроде бы и нечего.

А к чему вообще я пишу эту статью? Да к тому что хотел бы написать подобную систему и просто делюсь своими идеями с сообществом. И вдруг найдутся те кто бы с радостью были бы благодарными пользователями ее.

Спасибо за внимание.

Автор: serjx

Источник ^[1]