to post messages and comments.

@OCTAGRAM:

Сайты, которые нужно знать китайскому поклоннику открытых исходников:
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 тоже был. На трёх указанных китайских — нет. Беда. Глянул в китайскую вики, там тоже не видать своих сервисов.

@Self-Perfection:

Офигенный zstd, который работает в разы быстрее zlib, и при этом жмёт существенно сильнее, отличный кандидат на то, чтобы заменить zlib веде вообще. Вот первый уже пошёл: mercurial впилил zstd вместо zlib. Мозилловцы радуются

@max630:

ахаха bitbucket.org в фейсбуке фичу двигания файлов не оценили

@killy:

Наткнулся на 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.

@L29Ah:

Что нажать чтобы git↔hg?

@segfault:
hg Git ?

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

@max630:

pastebin.com вот поэтому и нельзя

а, да, и индекс не нужен же, зачем он

@k0st1x:

от opennet вышел на гугл-группу по mercurial,
там видно, что facebook пилят mercurial-сервер на Rust,
а Mercurial 4 будет наконец то работать на python3
groups.google.com

да и вообще на bitbucket оказывается есть публиные репы facebook, где они развивают hg
bitbucket.org

@Balancer:

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

@max630:

смотрите чего гугль заебашил bitbucket.org будут пропихивать в апстрим

@OCTAGRAM:

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

@Balancer:

добавлено 4102 наборов изменений с 4724 изменениями в 1256 файлах
Нормальное обновление :)

@Zert:

С удивлением узнал, что Go уже переехал с меркуриала на гит: golang.org
Вот это зрада так зрада. На меркуриале теперь что, вообще не осталось никаких значимых проектов?

@OCTAGRAM:

JScript не поддерживает UTF-8 с BOM. UTF-8 без BOM выдаёт ерунду в выводе консоли. ANSI/OEM не хочу. UTF-16LE с BOM определился и работает нормально, но теперь TortoiseHg считает файл двоичным.

@Zert:

Ртутекапец mercurial-scm.org

@max630:

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

@Zert:

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

@Balancer:

О! Нашёл, наконец, работающий вариант двухсторонней синхронизации git <-> mercurial.

github.com

@khades:
hg

mercurial <3

@Zert:

А вы ещё спрашиваете, почему я меркуриал обсираю: metaclass.livejournal.com
Повторил описанную ситуацию с гитом (используя touch -r, чтобы время модификации сохранить), не повторилась. С меркуриалом повторил без проблем.

@Zert:

Сука, надо закинуть в меркуриал патч, чтобы при hg init он выдавал ошибку и предложение создать репозиторий гитом.

@Zert:

Почему эта сифа не пишет прогресс при клоне?

@segfault:

github.com
До маджита как до китая раком, но основная функциональность работает.

@webus:

рванул с git обратно на hg. все же mercurial/hg удобнее в разы.

@provaton:

Жаль, что меркуриал медленно помирает. Мне он всегда нравился гораздо больше гита. linux.org.ru

@Balancer:

Есть тут спецы по git и его апологеты-холиворщики? Как вернуть данные и что с ними произошло? :) — linux.org.ru

@AlexVK:

Hg стал изрядно тормозить на проекте в момент клонирования репозитория.

@Balancer:

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

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

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

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

@Balancer:

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

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

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

@segfault:

А что, мне вот никак-никак нельзя исправить публичную ревизию?

@segfault:

проталкиваем в ...
поиск изменений
отдалённо: adding changesets
отдалённо: adding manifests
отдалённо: adding file changes
..........

ПРОТАЛКИВАЕМ ОТДАЛЕННО

@max630:

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

@Strephil:

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

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

@Tishka17:

кажется, придётся на время вернуться к системе контроля версий под названием tar

@segfault:

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

@datacompboy:

Господа! Кто пользует hg push github — какого лешего там мастер не обновляется на текущее положение?! O_O

@datacompboy:

А есть аналог tig'а для мерка?