Действительно ли распределенная система контроля версий не имеет централизованного хранилища?
Не существует принудительного центрального хранилища - это только по соглашению. Большинство проектов do имеют центральный репозиторий, но каждый репозиторий равен в том смысле, что они имеют полную историю, и могут вставлять и извлекать патчи между собой.
Один способ думать об этом - это централизованная VCS, фиксированная в топологии «звезда»: один центральный концентратор действует как сервер с полным хранилищем, с одним или несколькими клиентами, свисающими с него. Клиенты обычно имеют только копию самой последней чистой проверки и ограниченную историю (если есть). Таким образом, большинство операций требуют обратной передачи на сервер. Ветвление достигается созданием веток в одном хранилище.
В распределенной VCS топология вашей сети не ограничена. Вы можете теоретически иметь любую форму, которая вам нравится. У вас может быть отдельный репозиторий для каждой команды или подпроекта, а также этап коммитов. Вы можете иметь стабильный репозиторий и нестабильный репозиторий, а также множество ветвей функций и так далее. И нет никакого различия между клиентом и сервером - все узлы равны. Каждый репозиторий является автономным и полным и может выдвигать и / или извлекать изменения из любого другого. Для начала вы клонируете существующий репозиторий (создаете свою собственную копию для работы) и начинаете вносить изменения. Как только вы сделаете свой первый коммит, у вас фактически будет ветвь. К счастью, обычно очень легко объединить ваши изменения, когда вы закончите.
Но обычно 1016 * происходит, когда у вас есть один репозиторий, расположенный на центральном сервере, который облегчает людям начало работы и отслеживает, где находятся последние изменения.
как настроить рабочий каталог без сервера для проверки?
Ваш репозиторий должен начинаться где-то с исходного дерева. Таким образом, всегда есть первый репозиторий с начальной серией проверок. Допустим, вы хотите работать над Murky . Вы бы клонировали хранилище, которое дает вам полное хранилище со всей историей и регистрациями. Вы вносите некоторые изменения (таким образом, создавая ветку), и когда вы закончите, вы откладываете свои изменения назад, где они объединяются. Обе системы действуют как одноранговые узлы, и они выталкивают и вытягивают наборы изменений между собой.
И Mercurial, и Git хранят репозиторий в скрытом подкаталоге, поэтому одно дерево каталогов содержит как вашу рабочую копию (которая может находиться в любом нужном вам состоянии), так и само хранилище.
А как бизнес хранит надежную резервную копию репо?
Как и выше, у вас просто есть назначенный главный репозиторий, в котором есть все последние объединенные изменения, и создайте его резервную копию, как и все остальное. Вы можете даже иметь несколько резервных репозиториев или иметь автоматические клоны на физически отдельных блоках В некотором смысле, резервное копирование проще.
Полагаю, тогда должен быть центральный репо ... но тогда как именно он "распределяется"? Я всегда думал о различии сервер-клиент (SVN) и peer-2-peer (GIT), но я не верю, что это может быть правильным, если инструменты, подобные GIT, не зависят от технологии в стиле торрента?
Он не распространяется в том смысле, что разные клиенты имеют разные части, такие как одноранговый обмен файлами. Это действительно просто в отличие от централизованной модели.
Все репозитории DVCS являются гражданами первого класса. Это становится социальным или управленческим вопросом о том, как их организовать, а не техническим вопросом.