to post messages and comments.

Сайты, которые нужно знать китайскому поклоннику открытых исходников:
opencas.org
oss.org.cn

code.csdn.net
coding.net
git.oschina.net

Но при этом какой-нибудь tangram.baidu.com вполне может вести на банальный GitHub.

Думал, куда бы свалить с пидорского BitBucket. На международных CodePlex, BitBucket, Google Code, Assembla, SourceForge какой ни возьми, варианты SCM разные, и Mercurial тоже был. На трёх указанных китайских — нет. Беда. Глянул в китайскую вики, там тоже не видать своих сервисов.

Наткнулся на Git from the inside out (текст), понравилось.

Стало интересно, что происходит внутри при более сложных вещах — при редактировании истории. На ютубе есть ещё доклады, затрагивающие внутреннее устройство Гита, но они не идут сильно дальше этого.

Также захотелось увидеть что-то подобное про Mercurial. Видео не нашёл, и в процессе поиска вспомнил, что Меркуриал не задуман так, чтобы выставлять детали имплементации. Но если очень хочется, то официальная wiki — это наиболее содержательный источник информации. Начать удобнее всего оказалось с Mercurial for Git users и далее следовать по ссылкам на термины. В разделе Developer Info — Internals оказалось не густо.

На SO упоминаются статьи Behind the scenes и Towards a Better SCM: Revlog and Mercurial (гуглибельно, я не знаю нормальной ссылки), но они не слишком содержательны, по крайней мере на том уровне, на котором я хотел удовлетворить своё любопытство.

Одна деталь:
Аналогом команды git cat-file для просмотра внутренних бинарных файлов в Mercurial является подмножество команд hg debug*. Полный список дебажных команд удобнее получить через hg help debug.

hg Git ?

Я ведь правильно понял, что bookmarks в hg это ветки в git (причем, закладки в hg — локальные, их можно залить на удаленный репозиторий, но только в справочных целях, или хз) , теги — это теги, а ветки в hg — это вообще нёх. Каждый коммит типа помечается именем ветки, в результате ветка — это кусок графа коммитов, который может иметь несколько висячих голов, и есть специальные коммиты для "закрывания голов". Я представляю как это придумывалось, типа чтобы не терять код и не путаться в топологии веток, что от чего пошло, но вот у меня ветка с кучей голов, и что мне с ними делать? В гите эти головы будут просто именованными ветками, удалил ветку — "закрыл голову", а в hg и закладки не являются полноценными ветками, и ветки овердезайнутый кал.
Я всё верно понял?

Блин, как меня достало каждый раз при заведении сложного репозитория ломать голову, [email protected] или [email protected] На первом коммьюнити и внешние инструменты. На втором — беспроблемная работа. Ну не осиливаю я логику Git. 60+ репозиториев на GitHub и каждый день(!) приходится ломать голову, как победить очередные проблемы с коммитами. В то время, как в Mercurial всё просто молча работает не вызывая проблем... Это уже даже не карма какая-то, это идеологическая несовместимость, видимо :) Что делать, блин...

Пытаюсь понять, как держать актуальную версию. В hg я делаю pull, потом update, и я знаю, что update по умолчанию либо обновит, либо пожалуется, что у меня закралась пакость в этом каталоге, и я при необходимость могу сломать эту пакость через колено, сделав принудительное обновление, и у меня будет свежая версия из репозитория. Про git в Интернете пишут, что git pull = git fetch && git merge, но я не хочу merge. Если у меня что–то поменялось, я не хочу это сливать, а хочу свежую версию из репозитория. Не понимаю. Может, надо было через hg-git работать и не мучиться с этим непонятным git.

а есть какое-нибудь актуальная документация этого вашего hg evolve? Мне что-то только какие-то допотопные вики и блогпосты попадаются, которые ещё советуют екстеншен как не встроенный подключать и в которых картинки протухли.
И сразу уточнение — если верить evolution.experimentalworks.net , оно не отменяет всю эту ебанину с фазами, и чтобы обмениваться ребезящейся веткой надо заводить специальный репозиторий с publishing=false. Я правильно понял?

Кажется, есть шанс счастливо разрешить вопрос Mercurial vs Git :)

Опять же, за последние пару лет hg-git вылизали и он больше не вешается на моих репозиториях, а работает шустро, как и «родной» Git. Версии коммитов, правда, в Git'е оказываются другими, но это не так страшно, пока работаешь в одиночку.

Правда, как-то непонятно в статистике, пишет, что коммитов только 11 в master и 11 в другие бранчи, хотя на самом деле у меня только один master и коммитов тысячи. Но в целом — работает. Можно из привычного Mercurial работать с Git-репозиториями :)

Правда, на одном пушится почему-то только с --force. Ругается, типа: «прервано: pushing refs/heads/master overwrites 04265dac2ea2»

Прошёлся по современному состоянию серверов приложений, PaaS и прочему. Года два назад щупал, но не впечатлило ни разу. Потом следил только краем уха в теории. Сейчас полез — офигенно :) Выдают на халяву сразу виртуальные машины, готовые решения, порой, с полноценной ОС в виртуалке. OpenShift поюзал — интересно.

Надо будет по приколу привести свой фреймворк к варианту, легко разворачиваемому и в виде docker-образа, и на том же OpenShift.

И, похоже, судьба мне переезжать на GitHub :-/ Очень много сервисов, работающих с GitHub и git, но не работающих с Bitbucket и Mercurial. А жаль, мне Mercurial намного больше нравится :)
~~~

Вообще "зачем сохранять промежуточные версии" — вопрос нериторический. cvs — а её проприетарные аналоги ещё продаются за дикие бабки, и немалая доля тех кто принимает решения и обучает в вузах умеет только в них — в общем случае не гарантировала даже что ты сможешь счекаутить и собрать какую-то прошлую версию. Учитывая что писать внятные сообщения к коммитам они тоже не умеют и не учат — остаётся только функция "найти виноватого". Что, действительно, не так уж и ценно.

О системах контроля версий, почему их тут не используют:
«Если есть задача, если она поставлена, то программа либо с ней справляется, либо нет, третьего не дано.
Программа не может рабоать "лучше" или "хуже".
Либо она РАБОТАЕТ, либо она НЕ РАБОТАЕТ.
Поэтому, если есть рабочая версия, то разработка на этом закончена, это релиз. А если программа не дописана, тогда зачем сохранять промежуточные версии?»

И этот мудак еще преподаёт в ВУЗе.

Однако, аргументы в пользу hg начинают подкупать, вот хочу я посмотреть коммиты сделанные в ветке, а не могу, ибо узнать, где началась ветка невозможно, особенно после того, как ее слили в мастер. А вот в hg коммиты помечаются именем ветки (или уникальным id ветки?), поэтому там это не проблема, в теории.