Git vs Mercurial

bzr, кажись, умел (ты сам в толксы запостил).

Я?! Не может быть.

Ну и кроме того, мои убеждения (читай религия :)) и опыт говорят либо за Mercurial, который я знаю, либо за Git, который имеет и умеет практически все то же самое. Bzr — это темная лошадка скорее.

Не проще ли через Dropbox сразу держать папки с проектами синхронихированными?

подозреваю, что умеют оба, через какой-нибудь add remote repoxyz && pull repoxyz master, и даже наверное настроить чтобы оно работали просто по pull (http://justaddwater.dk/2009/08/23/how-to-add-git-pull-shortcut-to-different-g...) но вопрос а нафига?

чем обычная схема с мастер-репозиторием и двумя остальными, которые в него пушат, не подходит?

Я для этой цели mercurial использую (вообще, рабочих репозиториев штук 10, разработка ведётся на трёх-четырёх из них), но он тут от git, ИМХО, ничем не отличается.

Доступ к удалённым репозиториям обычно по sshfs. Только один центральный - по http гоняется.

>Доступ к удалённым репозиториям обычно по sshfs.

И как? Я раньше часто так работал, но онннооооо таккк мееееееееедленнноооо.

да и какой смысл в sshfs, если можно разрабатывать локально, а потом пушить по тому же ssh? это разве что если хочется править сразу удаленный репозиторий, но имхо такое желание от лукавого.

>И как? Я раньше часто так работал, но онннооооо таккк мееееееееедленнноооо.

На 16Мбит канале лимитируется каналом. На гигабитке качается где-то под 15Мбайт/сек. Конечно, в случае широкого канала это втрое медленнее, чем NFS, но для git/mercurial хватает с огромным запасом :) А для каналов меньше ста мегабит разницы просто не будет заметно...

>да и какой смысл в sshfs, если можно разрабатывать локально, а потом пушить по тому же ssh?

А разработка и ведётся локально. Просто таких «локальных» мест несколько :)

разве что если хочется править сразу удаленный репозиторий

Как думаешь, если у меня более десятка активных репозиториев, а правятся 3-4 из них - это с чем связано? ;)

...

Например, классическая схема:
- Боевой сервер.
- Тестовый сервер, являющийся точной копией боевого для проверок и тестов перед выкладыванием.
- Рабочий сервер, где происходит написание нового кода или глубокая правка старого.

Всё это - удалённое. Разнесено на две машины. Репозитории push/pop-ают по дефолту в указанной иерархии (т.е. pop на рабочем выдернет изменения тестового, а push на тестовом отправит изменения на боевой).

А ещё, например, есть домашняя машина, которая периодически дёргает все вышеописанные репозитории, например, для работы, когда не будет Интернета :)

>Как думаешь, если у меня более десятка активных репозиториев, а правятся 3-4 из них - это с чем связано? ;)

Специализация?

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

>я преимуществ первого не замечаю.

1. Настройки локального сервера и удалённого могут весьма отличаться.
2. Базы данных. Не всегда удобно перекачивать на локальную машину гигабайты удалённой БД для того, чтобы работать со свежими данными.
3. Картинки, файлы и прочие ресурсы - то же самое, что в пункте 2 :)

убедил.

> Я для этой цели mercurial использую (вообще, рабочих репозиториев штук 10, разработка ведётся на трёх-четырёх из них), но он тут от git, ИМХО, ничем не отличается.

Да, но как ты задачку решаешь? Делаешь pull на каждом руцями?

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

Проектик-то джаст фор май фан...

>Да, но как ты задачку решаешь? Делаешь pull на каждом руцями?

Да.

Мне это чуть геморно — я могу банально не упомнить, на каком компе и при каких обстоятельствах я сделал очередной кусок работы

Хм. Сделал кусок работы - сделал коммит. На то оно и VCS.

> Да.

Э, это я и сам могу. А вот чтобы автоматом на всех. :)

Хм. Сделал кусок работы - сделал коммит. На то оно и VCS.

Да, да, а потом сводить вместе деревья.

>Да, да, а потом сводить вместе деревья.

При частых коммитах это не проблема.