Комментарии 11
Можно попробовать построить такую штуку на принципах DHT. Там, насколько я в курсе, распределенная сеть жива пока живы хотя бы 2 её любых узла. Но вот будут ли этим действительно пользоваться…
Система контроля версий это система контроля версий, она не решает задачи бекапа и не обязана их решать, хоть и может технически.
Можно было бы много еще пообсуждать на тему возможностей быстрого восстановления утерянного центрального хранилища (хотя если честно редко, когда оно единственно, всегда ведь есть продакшн и зачастую есть тест-сервер) из копий репозитария рабочих машин (дело техники, как говорится), но главное не должно остаться за кадром — бекап. Банальный бекап без лишних велосипедов.
Можно было бы много еще пообсуждать на тему возможностей быстрого восстановления утерянного центрального хранилища (хотя если честно редко, когда оно единственно, всегда ведь есть продакшн и зачастую есть тест-сервер) из копий репозитария рабочих машин (дело техники, как говорится), но главное не должно остаться за кадром — бекап. Банальный бекап без лишних велосипедов.
Не раскрыт вопрос проблем с merge в вашей равнораспределённой архитектуре. Есть ощущение, что при >10 разработчиках консистентной версии, которую можно положить в билдферму и там собрать, никогда не будет.
Во время коммита выполненые изменения должны распространяться среди всех участников разработки. В результате у каждого разработчика будет одинаковое состояние репозитория.
В случае одновременных коммитов, система должна расчитывать очередность коммитов (возможно это будет в процессе общения между собой инициаторов данных коммитов), и эту информацию распростронять по учасникам, тем самым обеспечивая одинаковость истории и самого репозитория.
Мерджи — также как и сейчас, один выполняет у себя мерж, а потом распростроняет его среди всех остальных. По умолчанию это тот кто вливает ветку в мастер (короче инициатор этого мерджа).
В случае одновременных коммитов, система должна расчитывать очередность коммитов (возможно это будет в процессе общения между собой инициаторов данных коммитов), и эту информацию распростронять по учасникам, тем самым обеспечивая одинаковость истории и самого репозитория.
Мерджи — также как и сейчас, один выполняет у себя мерж, а потом распростроняет его среди всех остальных. По умолчанию это тот кто вливает ветку в мастер (короче инициатор этого мерджа).
У 10 разработчиков редко когда бывает одинаковый master. Наверное, вы не сталкивались с ситуацией: делаешь коммит, пуллишь мастер ветку, мержишь, пытаешься сделать пуш — а там уже ещё один коммит упал. Снова пулл, мерж, и потенциально опять феил при пуше. Иногда это развлечение растягивается надолго. А если будет 100 человек — то совсем беда. И все они никак не синхронизируются. Это первая половина проблемы.
Вторая половина — откуда билдферме брать правильную версию. Либо должен быть ответственный, который в специальное место выкладывает правильно смерженные исходники, либо ферма будет собирать что-то непонятное.
С очерёдностью коммитов тоже засада — мне приехали изменения от коллеги, я замержил всё, всё работает. Второй коллега тоже замержил к себе изменения первого, и присылает результат мне. Его коммит должен встать перед моим, но тогда у меня всё поломается. Его коммит может встать после моего, тогда мне надо его коммит мержить, а ему потом мёржить мой мёрж с его новым кодом. Код гарантированно (с точки зрения VCS) собирается только в одном случае — все коммиты присутствуют и располагаются в правильном порядке. Если хотя бы одного не хватает — никаких гарантий. Может быть, именно в том коммите была создана какая нибудь переменная, которую потом все активно используют.
Мне кажется, правильный ответ на ваш вопрос — идея то, может, и хороша, но технически не реализуема, не взлетит. С другой стороны, при изобретении вечных двигателей много всякого полезного напридумывали по ходу дела.
Вторая половина — откуда билдферме брать правильную версию. Либо должен быть ответственный, который в специальное место выкладывает правильно смерженные исходники, либо ферма будет собирать что-то непонятное.
С очерёдностью коммитов тоже засада — мне приехали изменения от коллеги, я замержил всё, всё работает. Второй коллега тоже замержил к себе изменения первого, и присылает результат мне. Его коммит должен встать перед моим, но тогда у меня всё поломается. Его коммит может встать после моего, тогда мне надо его коммит мержить, а ему потом мёржить мой мёрж с его новым кодом. Код гарантированно (с точки зрения VCS) собирается только в одном случае — все коммиты присутствуют и располагаются в правильном порядке. Если хотя бы одного не хватает — никаких гарантий. Может быть, именно в том коммите была создана какая нибудь переменная, которую потом все активно используют.
Мне кажется, правильный ответ на ваш вопрос — идея то, может, и хороша, но технически не реализуема, не взлетит. С другой стороны, при изобретении вечных двигателей много всякого полезного напридумывали по ходу дела.
Вы наверное не поняли основной механизм хранения данных. В системе у вас лежит репозиторий который всегда находится в HEAD ревизии. Этот репозитрий не является вашим рабочим каталогов. В вашем рабочем каталоге вы можете находиться хоть на 1000 ревизий назад, системе это не важно. Она работает только с локальным репозиторием. При обновлении вы получаете данные не от соседей а из этого репозитория.
С учетом этой поправки вышеописанные проблемы решаются также как и в git-е.
С учетом этой поправки вышеописанные проблемы решаются также как и в git-е.
Да, это немного другое. Но как система убедится, что у меня в этом репозитории все-все коммиты уже есть, перед тем, как положить туда мой? Чтобы мне что-то положить и не вызвать конфликтов, мой HEAD должен быть не старее, чем у кого либо ещё. Тут какая-то синхронность нужна. Может, какой нибудь PAXOS наворачивать надо. Только тогда в выходные дни никто коммит положить не сможет, потому что кворум не наберётся :)
Проблема отказоустойчиости выглядит крайне сомнительной.
rsnapshot (rsync) примененный раз в час к условно центральному серверу git решает описанную вами проблему на корню.
Ну да, минут 20 займет восстановит репозитории обратно на любой линукс машине.
Так исторически сложилось, что у нас два равноправных сервера с репозиториями git. Один во внутренней сети, с него разворачивается куча сервисов,
второй снаружи, у него канал лучше.
Любой упадет — даже торопиться не будем, день-два обойдемся, а там и руки дойдут резервную копию резвернуть.
rsnapshot (rsync) примененный раз в час к условно центральному серверу git решает описанную вами проблему на корню.
Ну да, минут 20 займет восстановит репозитории обратно на любой линукс машине.
Так исторически сложилось, что у нас два равноправных сервера с репозиториями git. Один во внутренней сети, с него разворачивается куча сервисов,
второй снаружи, у него канал лучше.
Любой упадет — даже торопиться не будем, день-два обойдемся, а там и руки дойдут резервную копию резвернуть.
Главный сервер можно держать в облаке и обеспечивать его отказоустойчивость на совершенно другом уровне, чтобы не усложнять схему работы контроля версий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пожаробезопасность в системах управления версиями