Mercurial 1.3

Где его не хватает?

> а ведётся какая-то [активная] работа в этом направлении?

Насчет "активной" не знаю, но последние коммиты в hgsubversion - 16 июня.

> И что насчёт итеративного перетаскивания из/в git'овый репозиторий

hg help convert (это уж года 3 работает, хотя переименования до сих пор не отслеживает), http://hg-git.github.com находится в разработке, Мэтт собирается сделать поддержку 2-3 типов "неродных" репозиториев в 1.4

> tailor

Ыыыы, какая древность. Неужели оно еще живо?

> Исходный посыл:

>>изменения будут аккуратно вырезаны из текущего бранча, и объединены с нужным

"Вырезаны" означает, что их в текущем бранче не останется, то есть семантика mv, а не cp. transplant же дает именно cp.

> Юникод так и не прикрутили.

Юникод прикрутили уж несколько лет как. Чего не хватает?

Кстатиб вышел новый TortoiseHg: http://www.selenic.com/pipermail/mercurial/2009-July/026540.html

Можно сделать transplant и потом rollback. На rebase исходный посыл похож еще меньше, энивей.

> Можно сделать transplant и потом rollback

Не rollback, а strip.

> На rebase исходный посыл похож еще меньше, энивей.

По сути, rebase == transplant + strip

я может что-то не понимаю, но где же в "концепции" rebase есть "strip"?

в моем понимании rebase всегда был "недеструктивной" операцией по отношению к версии, с которой делают rebase.

а человек изначально просил "деструктивное" действие...

Или в mercurial rebase имеет свое собственное значение, не как у всех?

> в моем понимании rebase всегда был "недеструктивной" операцией по отношению к верси

rebase деструктивен по отношению к графу истории - цепочка коммитов (возможно, модифицированных) ВНЕЗАПНО возникает в другом месте графа, и исчезает из старого.

Уууу блин... вот так дела... в mercurial совсем не такие бранчи, как я думал до этого...

сам я человек испорченный clearcase (производственная травма так сказать :)) mercurial использую постоянно, но никогда не пользовался бранчами...

сейчас быстро протестировал rebase... да, и правда, он деструктивен в mercurial... в clearcase все по-другому :))

Спасибо, буду знать.

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

А я даже не понимаю, зачем они нужны - в BitKeeper их не было, что не мешало ему поддерживать немаленькое ядро. Клоны - наше всё.

Кстати, бранчей в Mercurial 2 или даже 3 вида - 1-2 встроенных, и 1 через расширение.

> А я даже не понимаю, зачем они нужны

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

> клонировать.. зачем это надо если отличия будут всего в паре-тройке файлов (из 5-6 тысяч)

И что? Создать клон - минутное дело (у меня на ноуте репозитарий ядра клонируется 1 мин 40 сек), при том, что основное время тратится на checkout. Если для тебя эти 1.5 минуты критичны, just use mq. Не вижу необходимости в бранче.

ну, на вкус и цвет... мне лично удобнее с бранчами.

> ну, на вкус и цвет...

О чем и речь... пиар это всё.

> мне лично удобнее с бранчами.

Если речь о git-подобных бранчах, то их копия есть в Mercurial через плагин.

git-подобные бранчи, это hgtasks чтоли?

> А я даже не понимаю, зачем они нужны - в BitKeeper их не было, что не мешало ему поддерживать немаленькое ядро. Клоны - наше всё.

кстати да, в Ericsson AB думают по-другому :))

> git-подобные бранчи, это hgtasks чтоли?

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

>> Клоны - наше всё.

> кстати да, в Ericsson AB думают по-другому :))

А они юзают Mercurial?

За ссылку спасибо

> А они юзают Mercurial?

нет, они юзают ClearCase :) и бранчей в среднем проекте дохера :) под каждую новую версию релиза заводится отдельный бранч, а уж сколько промежуточных бранчей там существует... клонировать тут мне кажется мягко говоря непродуктивно (учитывая объемы кода).

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