Посоветуйте систему управления версиями для распределенной разработки

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

Т.е. вы не хотите иметь центральный репозиторий вообще? Довольно экзотическое требование...

А вобще может попробовать использовать ветви (в CVS и subversion эти понятия точно есть). Каждый разработчик ведет свою собственную ветку, и синхронизация заключается в копированиии изменений из одной ветки в другую, т.е. только между двумя разработчиками(опосредовано через центральный узел), не затрагивая остальных.

ЗЫ: мое предложение основано только на чтении документации, реально я не пробовал. Так что если случайно уничтожите репозиторий - сильно меня не пинайте :)

Посмотри на tla. Может там что-нить есть полезное

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

Что-то не припомню систем с возможностью синхронизации каждый с каждым. Все-равно кто-то должен выступать "ценральной" точкой.

Если нужна система, позволяющая работать с локальными копиями репозитория, то посмотри svk.

darcs - самое простое

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

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

ИМНО cvs веткп - пральное решение...

>Что-то не припомню систем с возможностью синхронизации каждый с каждым. Все-равно кто-то должен выступать "ценральной" точкой.

Уже назвали: tla (gnu arch, вроде, полное название http://www.gnu.org/software/gnu-arch/)

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

> Он все-равно требует централизованного хранения конечного результата.

Не требует.

> Можно, конечно, вносить изменеия и в свой репозиторий, и в репозитории других разработчиков.

Нет, не так, а

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

>> Он все-равно требует централизованного хранения конечного результата.

> Не требует.

>> Можно, конечно, вносить изменеия и в свой репозиторий, и в репозитории других разработчиков.

> Нет, не так, а

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

С центральным репозиторием каждый разработчик использует следующий сценарий:

1. Создает зеркало удаленного репозитория, 2. Создает локальную ветку проекта, 3. Извлекает рабочую версию, 4. По необходимости синхронизирует рабочую версию с локальной веткой, 5. Также по необходимости синхронизирует локальную ветку с удаленным репозиторием.

То есть вся синхронизация идет через одну точку.

Какой будет сценарий при отсутсвии центрального репозитория и при наличии нескольких разработчиков?

> Какой будет сценарий при отсутсвии центрального репозитория и при наличии нескольких разработчиков?

1. Создаёт локальный репозитарий

2. Создаёт зеркало локального репозитария для доступа остальным разработчикам.

3. Инициирует локальный репозитарий. Например, сразу мержит версию кого-либо из разработчиков.

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

BitKeeper как-то решил негромоздко, стабильно и понятно

Еще один совет. Используй google. Я там находил замечательное сравнение OS-ных систем. По памяти в порядке убывания предпочтительности (несколько субъективно) - darcs, monotone, arch(AKA tla) - вполне подходят. Возможно есть еще 1-2.

Всем спасибо за ответы!

watashiwa_daredeska более внятно описал требуемую схему работы, нежели это получилось у меня.

Буду сравнивать darcs, monotone и arch.

Можно подробнее? Например:

1.1. Третий разработчик делает локальную копию ветки первого разработчика. Работает с этой копией. Каким образом выбирается ветка для копирования? Можно брать произвольную или разработчики должны договориться об одной определенной ветке?

1.2. Третий проводит слияние изменений ветки второго и своей локальной ветки. Как находится общая точка удаленных репозиториев для слияния, автоматом (если да, то на основании чего) или указывается вручную?

1.3. Первый забирает изменения у третьего. Из какой ветки он это делает? Он увидит, где изменения, взятые третьим у второго, а где изменения сделанные самим третьим?

1.4. Первый забирает изменения у второго. У него уже будет часть изменений второго, которые он получил через третьего? Если да, то это как-то будет определено?

2. У кого находится проект с текущим состоянием?

3. Каждый помимо своих конфликтов должен разрешать еще и чужие?

4. Есть где-нибудь описания этого сценария? Полистал wiki.gnuarch.org -- не нашел.

>Можно подробнее? ...

Веток нет. Ветка есть множество патчей. Слияние веток есть "производство" версии из обьединения множеств патчей. Вопросы 1.х исчезают. Можно в darcs-е почитать про "алгебру патчей".

>2. У кого находится проект с текущим состоянием?

У каждого свое текущее состояние. Кто-то отвечает за "выпуск" продукта - он и отбирает нужные новой версии патчи.

>3. Каждый помимо своих конфликтов должен разрешать еще и чужие?

Если "A" обнаружил конфликт патчей от "Б" и "В" - он может попросить одного из последних затащить себе патч другого, после чего затащить результат себе. Это будет эквивалентно "централизованой" версии.

То есть на определенном этапе центральные точки появляются (большей частью для удобства управления проектом).

>То есть на определенном этапе центральные точки появляются

Сколько может быть "центральных" точек?. (хотя можно придумать такое определение слова "центральный"...)

Если это о словах "Это будет эквивалентно 'централизованой' версии" - то они неправильно поняты - имелось ввиду, что разешать конфликты _могут_ некоторые из тех, кто их породил. А могут другие - если у них это лучше получается.

> Сколько может быть "центральных" точек?. (хотя можно придумать такое определение слова "центральный"...)

Репозитории, в которых разрешаются конфликты, хранятся версии проекта.

> Если это о словах "Это будет эквивалентно 'централизованой' версии" - то они неправильно поняты - имелось ввиду, что разешать конфликты _могут_ некоторые из тех, кто их породил. А могут другие - если у них это лучше получается.

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

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

>Репозитории, в которых разрешаются конфликты, хранятся версии проекта.

Тогда, пожалуй, в darcs/monotone/tla центральных репозиториев просто дофига - у каждого разработчика по несколько:-)

>Как определить, кто должен? Где это будет происходить? Как об этом узнают другие?

<imo> Это не проблемы vcs-ов и решений может быть много. А системы с центральным репозиторием сужают пространство возможных решений. Как то(на примере cvs-а): конфликты должен решать коммитящий последним или ответственный за merge, в своей рабочей копии, другие об этом узнают по задержке строков его коммита и повторить его работу не смогут по причине отсутствия результатов его работы в репозитории... </imo>