Распределенная Система управления версиями действительно не имеет никакого централизованного репозитория?

При распределенном управлении версиями вы можете иметь полную копию всей истории (всего репозитория), встроенную как часть вашей локальной (извлеченной) копии.

В дополнении у большинства проектов будет центральный репозиторий, в котором также будут все копии. Это означает, что в какой-то момент вам нужно будет отправить ваши изменения из локального репозитория в центральный. Но это также означает, что вы можете работать локально сколько душе угодно, а затем продвигать только те изменения, которые вы хотите продвинуть, и вам нужно продвигать их только тогда, когда вы будете готовы.

Например, посмотрите на ядро ​​Linux: многие люди будут откуда-то «клонировать» дерево ядра. Это может быть дерево Линуса или одно из других деревьев, плавающих на kernel.org или в Интернете. Но дерево Линуса существует как на kernel.org, так и (предположительно) также на компьютере (ах) Линуса (и на компьютерах всех, кто оттуда извлек).

В последнем сообщении в блоге Джоэла лучше всего описаны преимущества (и основные отличия от таких систем, как Subversion) DVCS:

Когда вы управляете изменениями вместо управления версиями, слияние работает лучше, и, следовательно, вы может разветвляться в любое время, когда этого требуют ваши организационные цели, потому что обратное слияние будет простым делом.

Итак, вы помещаете копию дерева на какой-то центральный сервер где-нибудь, откуда другие люди могут извлечь (или на ваш частный сервер, чтобы у вас была резервная копия), и когда вам это нравится, вы переносите туда некоторые биты. Затем, если кому-то нужна копия, они могут клонировать оттуда.

Аналогия "peer-to-peer" относится к тому, как вы получаете изменения из другого репозитория.

• В DVCS вы получаете изменения, а затем выбираете их слияние, если хотите.
• В CVS вы обновляете изменения, которые влияют непосредственно на ваше рабочее пространство

Поскольку вы можете получать изменения из любого другого "однорангового" репозитория (репозитория, имеющего один и тот же первый коммит), вы можете считать это одноранговой моделью, поскольку:

Одноранговые ресурсы являются как поставщиками, так и потребителями ресурсов, в отличие от традиционной модели клиент-сервер, где только серверы поставляют, а клиенты потребляют.

Здесь необходимо сделать важное различие: существует ли технический центральный сервер или он условно ].

Технически все клоны репозитория git эквивалентны. Все они позволяют изменения, отметки, переходы, слияние друг с другом. Нет ни одного репозитория, который был бы «более правдивым», чем любой другой.

По общественному соглашению большинство проектов, использующих git, имеют центральный репозиторий, который считается авторитетным репозиторием, представляющим официальное состояние проекта.

Сравните это с более традиционной VCS, такой как SVN: здесь центральный репозиторий технически сильно отличается от локальной кассы, которая может быть у каждого разработчика. Локальный выезд может выполнять операции VCS только по отношению к центральному репозиторию. Без центрального репозитория разработчик не может совершить коммит.

Технически, DVCS не нуждается в централизованном хранилище.

В реальной жизни приложение (например, ядро Linux) должно быть собрано из единой согласованной коллекции источников перед поставкой.

Таким образом, DVCS не навязывает никакой политики управления исходными текстами и оставляет принятие таких решений на усмотрение менеджеров проектов.

Технически вам не нужен центральный сервер: вы можете просто обмениваться коммитами со своими коллегами, и все.

Логично (просто взгляните на github.com) ВСЕГДА будет (по крайней мере) центральный репозиторий, своего рода «главная копия», на которую вы можете положиться. Я полагаю, что в ядре Linux репозиторий Линуса является главным репозиторием, из которого в конечном итоге принимаются изменения, не так ли?

Я думаю, что это будет особенно верно для компаний, использующих DVCS: они не будут полагаться на копии разработчиков. "но централизованные, хотя, очевидно, может быть БОЛЬШЕ, чем одна копия (что тоже очень хорошо, чтобы избежать катастрофы :-P, и происходит довольно естественно с DVCS)

Действительно ли распределенная система контроля версий не имеет централизованного хранилища?

Не существует принудительного центрального хранилища - это только условность. Большинство проектов имеют центральное хранилище, но каждое хранилище равноправно в том смысле, что у них есть полная история, и они могут перебрасывать и перетягивать патчи друг другу.

Можно представить себе централизованный VCS в виде звезды: один центральный узел действует как сервер с полным репозиторием, а один или несколько клиентов висят на нем. Клиенты обычно имеют только копию последней чистой проверки и ограниченную историю (если таковая имеется). Поэтому большинство операций требуют обращения к серверу. Разветвление достигается путем создания ветвей внутри одного репозитория.

В распределенной VCS нет ограничений на топологию вашей сети. Теоретически вы можете иметь любую форму. Вы можете иметь отдельный репозиторий для команды или подпроекта, с поэтапным распределением коммитов. У вас может быть стабильный репозиторий и нестабильный репозиторий, множество ветвей фич и так далее. И нет различий между клиентом и сервером - все узлы равны. Каждый репозиторий является самодостаточным и законченным, и может получать и/или извлекать изменения из любого другого. Чтобы начать работу, вы клонируете существующий репозиторий (создаете свою собственную копию для работы) и начинаете вносить изменения. Как только вы сделаете свой первый коммит, у вас фактически появится ответвление. К счастью, обычно очень легко слить свои изменения обратно, когда вы закончите.

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

как создать рабочий репозиторий без сервера для проверки?

Ваш репозиторий должен где-то начинаться с дерева исходников. Поэтому всегда есть первый репозиторий с начальной серией проверок. Допустим, вы хотите работать над Murky. Вы клонируете репозиторий, что дает вам полный собственный репозиторий, со всей историей и проверками. Вы вносите некоторые изменения (создавая таким образом ответвление), а когда закончите, вы отсылаете свои изменения обратно, где они сливаются. Обе системы действуют как равные, и они пересылают и перетягивают наборы изменений друг другу.

И Mercurial, и Git хранят репозиторий в скрытом подкаталоге, так что в одном дереве каталогов содержится и ваша рабочая копия (которая может быть в любом состоянии), и сам репозиторий.

А как предприятие хранит безопасную резервную копию репозитория?

Как и в предыдущем случае, вы просто имеете назначенный мастер-репозиторий, в котором хранятся все последние слитые изменения, и создаете его резервную копию, как и все остальное. Вы даже можете иметь несколько резервных копий репозитория или автоматические клоны на физически отдельных ящиках. В некоторых отношениях резервное копирование проще.

Я предполагаю, что тогда должно быть центральное хранилище... но тогда как именно оно "распределено"? Я всегда думал о различии между сервером-клиентом (SVN) и peer-2-peer (GIT), но я не верю, что это может быть правильным, если только такие инструменты, как GIT, не зависят от технологии типа torrent?

Он не распределен в том смысле, что разные клиенты имеют разные части, как в пиринговом файлообмене. Это действительно просто контраст с централизованной моделью.

Все репозитории DVCS - граждане первого класса. Это становится социальным или управленческим вопросом о том, как их организовать, а не техническим вопросом".