[Опасность флейма] Выбор VCS

Mercurial.
+ не тормозит
+ удобный CVS'образный синтаксис команд
+ работает под виндами
+ интегрируется в trac
- нет морды (виндовым юзерам это может быть важно)

АФАИК у darcs-а проблемы с большими объёмами. git в целом быстрее mercurial-а, mercurial - удобней (субъективно).

Использую git и не могу нарадоваться :-). Работает весьма шустро, хорошо испытан на проектах большого объема (ядро Linux, Альтовский Сизиф). Отлично документирован. Есть отличный нативный шлюз в SVN. Увы, сравненить не могу -- сразу лег в руку, поэтому ничего больше не искал.

> git - работает шустро, но ведёт себя слегка загадочно

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

> (как он работает с симлинками

А что не так с симлинками? Это ж просто строка с путем. У меня отлично сохраняет и поднимает...

> и выбирает какие файлы изменились я до конца так и не понял - выдаёт бред)

Где выдает бред? АФАИК, просто высчитывается хэш по MD5, и по нему определяется, что изменилось, а что нет. Если файл переименовывается или перемещается в другой каталог, то по хэшу отслеживается, что это тот же самый файл, и это отображается в истории.

>Mercurial. ...(skipped)...

А как у него со сложностью подъёма сервера?

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

>> Mercurial. ...(skipped)...

> А как у него со сложностью подъёма сервера?

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

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

А еще у Mercurial есть Hg Book, которая тебе очень рекомендуется к прочтению :)

http://hgbook.red-bean.com/

http://www.selenic.com/mercurial/wiki/

git.

> git.

Доводы?

monotone больше не котируется?

>monotone больше не котируется?

Не сталкивался. Какие плюсы/минусы?

> monotone больше не котируется?

А она когда-то котировалась? Ее идеи легли в основу Mercurial и Git, так что свое дело она уже сделала :)

Видимо, за git-ом мейнстрим. Соотв. уровень поддержки и пр...

ЗЫ Сам не пользовал распределенных вообще

Использую Mercurial, доволен. Git последний раз трогал полгода назад, и заключил, что пользоваться им можно, если сильно припрёт, но желания такого он не вызывает, из-за несколько, гм, своеобразного подохода к юзабилити. Если кто объяснит, какие преимущества у него с тех пор появились перед меркуриалом, с удовольствием почитаю.

> - нет морды (виндовым юзерам это может быть важно)

А как же hg view? ;) Ещё есть плагин для Eclipse.

> Видимо, за git-ом мейнстрим.

За Git - фигура Линуса. Это круто - пользоваться системой, которую разработал САМ! "Рядом с такой сокровищницей мысли чувствуешь себя чище, как-то духовно растешь" (c)

OpenSolaris и Mozilla используют Mercurial, так что о мэйнстримности можно спорить :)

> Соотв. уровень поддержки и пр...

С Вендой дела у Git паршиво, так что для кросс-платформенной разработки он не очень (поэтому Mozilla выбрала Hg).

> За Git - фигура Линуса.

Не только (хотя да, это важно). Еще xorg и некоторые другие хорошо видимые проекты.

> С Вендой дела у Git паршиво

Да, это существенный недостаток. Если починят - будет просто киллер vcs

>> За Git - фигура Линуса.

> Не только (хотя да, это важно).

ИМХО, это единственное _существенное_ преимущество.

> Еще xorg и некоторые другие хорошо видимые проекты.

Не знаю насчет WINE, но как Xorg переходил на git - это просто офигеть: пришел Пакард и сказал, что у него есть знакомый спец по Git, поэтому переходим на него со вчерашнего дня :D

>Да, это существенный недостаток. Если починят - будет просто киллер vcs

Скажите, а какие у git преимущества перед тем-же Mercurial?...

http://lwn.net/Articles/138146/

+ http://groups.google.com/group/linux.kernel/browse_thread/thread/c7ca84d03736...

> http://lwn.net/Articles/138146/

Это типа шутка такая? o_O

> Это типа шутка такая? o_O

блин, на lwn оказывается обсуждение покаццали. в git mailing list можно поискать, там обсуждение - самый смак.

> блин, на lwn оказывается обсуждение покаццали

Блин, да это же 2 года назад было :) Как пользователь Mercurial со стажем могу сказать, что он сильно изменился за это время. К Git, впрочем, это тоже относится - говорят, начиная с версии 1.5 им и в самом деле можно пользоваться без опасности перелома мозга :)

обсуждения, которые можно прочитать, сходив по второй ссылке, порсто показывают некоторые фундаментальные отличия этих двух vcs.

You've not mentioned two out of my three design goals: - distribution - reliability/trustability

ie does mercurial do distributed merges, which git was designed for, and does mercurial notice single-bit errors in a reasonably secure manner, or can people just mess with history willy-nilly?

For the latter, the cryptographic nature of sha1 is an added bonus - the _big_ issue is that it is a good hash, and an _exteremely_ effective CRC of the data. You can't mess up an archive and lie about it later. And if you have random memory or filesystem corruption, it's not a "shit happens" kind of situation - it's a "uhhoh, we can catch it (and hopefully even fix it, thanks to distribution)" thing.

I had three design goals. "disk space" wasn't one of them, so you've concentrated on only one so far in your arguments.

Linus

вот кстати ещё несколько прелюбопытнейших ссылочек с wiki:

http://lwn.net/Articles/151624/

http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html?page=1( Subversion or CVS, Bazaar or Mercurial?) 2007

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

Нет в них никаких фундаментальных отличий. Просто _нет_. А Линус слишком уж неровно дышит к своему детищу (см. выступление в Google).

> ie does mercurial do distributed merges, which git was designed for,

Да, mercurial does distributed merges, и тоже был designed for them.

> and does mercurial notice single-bit errors in a reasonably secure manner

да, mercurial does.

> or can people just mess with history willy-nilly?

В Mercurial историю изменить даже труднее, чем в Git,

> I had three design goals. "disk space" wasn't one of them

Ога, ога... это прокатит с теми, кто не следил за историей.

Еще раз повторю: Линус и git@ - это не самые объективные источники информации о Git.

Еще раз - технически не возьмусь обосновать. Я просто слежу за некоторым куском коммюнити, где народ всяко продвигает git. Мне кажется, у нее есть то, что у буржуев называется словом momentum (как это хорошо на русский перевести?)

ЗЫ Народ, сравнивать системы, развивающиеся так быстро, по обзорам двухлетней давности - это даже не смешно. Независимо от результатов обзоров.

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

hm... мне почему то казалось, что это умеет и SVN, нет?

// wbr

> hm... мне почему то казалось, что это умеет и SVN, нет?

Локальной контролировать версии?

>> hm... мне почему то казалось, что это умеет и SVN, нет?
> Локальной контролировать версии?

mmm... в смысле назначать номер версии? думаю, что навряд ли, хотя никогда особо над этим не задумывался. но локально он умеет управлять деревом проекта (add/remove/rename/etc) + прочие мелочи, которые потом можно одним большим commit-ом засандалить в головной сервер когда он будет доступен. мне в CVS собственно их и не хватало.

// wbr

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

> hm... мне почему то казалось, что это умеет и SVN, нет?

Смотря что понимать под "работать локально".

> Смотря что понимать под "работать локально".

у меня есть копия репозитория, которая также является полноценным репозиторием. я могу делать в ней любые локальные изменения(правка кода, создание новых бранчей и тагов, переиндексацию/etc), а потом могу либо замержить свои изменения в оффициальную ветку, либо создать новый бранч и замержить, либо использовать свою копию репозитория в кач-ве сервера.(в git'e кстати делается одной командой).

>> Смотря что понимать под "работать локально".

> у меня есть копия репозитория, которая также является полноценным репозиторием.

Мужыыыыык :) я знаю, что ты понимаешь. Я и сам понимаю. Но вопрос был в том, что понимает под этим OP :)

> использовать свою копию репозитория в кач-ве сервера.(в git'e кстати делается одной командой).

В Mercurial - тоже :D

> В Mercurial - тоже :D

хм, что ж, покопаем, посмотрим.

Read-only копии репозитариев, с которыми потом можно работать и далее синхронизировать их с центральным, умеет SVN >=1.4. Читай доку по svnsync.

> Read-only копии репозитариев, с которыми потом можно работать и далее синхронизировать их с центральным, умеет SVN >=1.4. Читай доку по svnsync.

Толку-то, если коммитить всё равно приходится в центральный репозиторий.

Автора темы, возможно, устроит вариант "read-only", если исходить из фразы "Хочется иметь возможность работать локально, но в последствии заливать всё в общий репозитарий."

>Автора темы, возможно, устроит вариант "read-only", если исходить из фразы "Хочется иметь возможность работать локально, но в последствии заливать всё в общий репозитарий."

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

ЗЫ: За заливку "одним огромным коммитом" (по крайней мере в SVN) нужно мочить в сортире...;)

> За заливку "одним огромным коммитом" (по крайней мере в SVN) нужно мочить в сортире...;)

Безжалостно и неуклонно :D

> - нет морды (виндовым юзерам это может быть важно)

Это скорее тоже в + записывать надо. Таких юзеров от проекта отвадить - весьма полезно.

>> - нет морды (виндовым юзерам это может быть важно)

>Это скорее тоже в + записывать надо. Таких юзеров от проекта отвадить - весьма >полезно.

кстати морда таки есть:

GUI interfaces for Mercurial include Hgk (Tcl/Tk). This is implemented as a Mercurial extension, and is part of the official version. This viewer displays the directed acyclic graph of the changesets of a Mercurial repository. This viewer can be invoked via the command 'hg view', if the extension is enabled. hgk was originally based on a similar tool for git called gitk.

Related tools for merging include (h)gct (Qt) and Meld.

http://en.wikipedia.org/wiki/Mercurial_%28software%29#Related_software

Пока пробую Mercurial. Пока нравится. Сразу возник вопрос: можно ли в нём сделать что-то на подобе SVN'вского атрибута 'external'?...

Использую git. Ну очень доволен!

P.S. mercurial не пробовал..

Так, понятно. Эта фича возможна только с использование расширения hgforest.

2All: А в git'е такое делать можно?...

А про BZR что-нибудь расскажите?

> А про BZR что-нибудь расскажите?

Он тормозит.

Помню, смотрел какие-то бенчмарки, он тормознее git'a в константное количество раз. Не так уж и страшно, учитывая что он на Python написан. Или что-то другое имеется в виду?

> Помню, смотрел какие-то бенчмарки, он тормознее git'a в константное количество раз. Не так уж и страшно

Причем константа довольно большая - несколько раз.

> учитывая что он на Python написан.

Mecrcurial тоже на Питоне, но идет почти вровень с git (где-то проигрывает git проценты, где-то выигрывает).

Почитать бы где обширное сравнение все этих VCS. Мне в bzr понравилась возможность назначения удаленным репозитариям человеческих алиасов. То есть, назвать, например, https://somehost:8080/somepath именем Maxim.

> Мне в bzr понравилась возможность назначения удаленным репозитариям человеческих алиасов

Фигня какая :)

добавь в свой .hgrc

[paths] Maxim = https://somehost:8080/somepath

stupid me! thanks :)