LINUX.ORG.RU

Закладки в Mercurial - как ими пользоваться, ёпт?

 ,


1

5

[tldf закладки неюзабельное говно]

Вот всем меркуриал хорош, в отличие от наркоманского гита - кроме веток. Потому что ветка в гите - это как сейва в игре. Посейвил текущий момент в истории, и в любой момент можешь к нему вернуться, просто и гениально. Меркуриал-овцы любят повторять: «Так у нас есть закладки!!!» Да нифига.

Вот хотим мы с помощью закладок сделать feature branch. Создаём закладку, пишем код, коммитим, радуемся:

$ hg update default                    # переходим в самую последнюю ревизию основной ветки
$ hg bookmark blackjack-and-hookers    # это будет наш feature branch
$ vim src/hookers.c
$ hg ci -Am 'Add hookers'
$ vim src/blackjack.c
$ hg ci -Am 'Add blackjack'            # почти готово, ништяк

И тут нам понадобилось вернуться в основную ветку. Што? Где она? hg update default - ничего не происходит!
$ hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

Потому что меркуриал всё это вермя тихо складывал наши изменения прямо в основную ветку, и она тихо ехала вслед за нашими коммитами, и теперь указывает туда же, куда и наша feature branch:
$ hg identify --rev default
aab62191150e tip blackjack-and-hookers
$ hg identify --rev blackjack-and-hookers 
aab62191150e tip blackjack-and-hookers

Указатель на реальную «основную ветку», от которой мы отпочковали feature branch, нигде не сохранился. В меркуриале ведь никогда ничего не теряется, в отличие от гита... wait... ОХ БЛ

Потому что закладки в меркуриале - это не бранчи, как в гите. Это непонятно что, прикрученное сбоку синей изолентой. Меркуриалу пофигу, что для нас это feature branch - для него мы по-прежнему в основной ветке. Меркуриал как бы говорит: «Надо тебе - сам следи за своей основной веткой. Создай ручками закладку default и ручками её переставляй. Можешь на бумажке записывать номера ревизий, это даже проще. И не забывай отныне вместо push делать push -B default, а то твой feature branch тихо и незаметно вольётся в основную ветку. Ах, так его не надо было вливать? Тогда ты должен был установить на ревизии из feature branch фазу secret - у нас же не гит-наркомания, у нас же всё просто! Ах, тебе всё-таки надо куда-то пушить feature branch, но не в основной репозиторий? А мне тогда пофиг, лол. Тебе надо ты и пердолься, как хочешь.»

Вопрос к меркуриал-овцам: вы реально этими закладками пользуетесь для feature бранчей? Или их в меркуриале сделали только для отмазы, чтобы гит-фанбоям отвечать «у нас тоже есть»? Сколько ещё лет потребуется, чтобы довести закладки до юзабельного вида? Шёл 2015 год. Доля hg-юзеров неуклонно снижалась. Медленно приближался конец поддержки Python2... Это отчаяние?



Последнее исправление: HeipaVai1o (всего исправлений: 1)

Ответ на: комментарий от Reset

Слил свою личную feature-branch в master и сам удалил ветвь.

Слить, а потом удалить ветвь невозможно, если сливать при помощи merge. Если не сливать, а извращаться с export/import, graft и т.п., то это просто неудобно.

Sorcerer ★★★★★
()
Ответ на: комментарий от tailgunner

Короткоживущая (дни) личная ветка - mq

А вот я mq не использую для этих целей. Вместо того, чтобы запоминать альтернативную систему команд, по-моему удобнее просто коммитить ревизии как обычно, для редактирования цепочки пользоваться histedit, а для перемещения всей цепочки на новый head - rebase. В histedit недавно добавили команду roll, так вообще хорошо стало (до этого я сам себе патчил histedit, чтобы была команда roll).

Sorcerer ★★★★★
()
Ответ на: комментарий от waker

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

maloi ★★★★★
()
Ответ на: комментарий от Sorcerer

запоминать альтернативную систему команд

Да там команд - qnew, qpush, qpop, qref. Впрочем, я проникся идеей еще во времена quilt.

по-моему удобнее просто коммитить ревизии как обычно, для редактирования цепочки пользоваться histedit, а для перемещения всей цепочки на новый head - rebase

Набор команд mq простой и оптимизированный под задачу, а ты, насколько я понимаю, делаешь evolve вручную. Может, иногда это и лучше (когда исправление нижнего патча вызывает конфликты при наложении верхних), но, ИМХО, в 90% случаев - лишние сложности.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Тут дело привычки, я так думаю.

Но по мне так сложностей даже меньше. Часто бывают ситуации, когда несколько незакоммиченных изменений в коде надо разнести по разным changeset'ам. Если известно, что они не будут конфликтовать, если их закоммитить относительно head, то можно сразу выполнять пачку коммитов, указав только при коммите ссылку на оригинальный коммит, для которого они предназначены. Потом один раз запустить histedit и переупорядочить/объединить всё.

Sorcerer ★★★★★
()
Последнее исправление: Sorcerer (всего исправлений: 1)
Ответ на: комментарий от Reset

Зачем весь мусор сливать в общий репозиторий?

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

waker ★★★★★
()
Ответ на: комментарий от maloi

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

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

waker ★★★★★
()
1 октября 2015 г.
Ответ на: комментарий от Sorcerer

"это фича"

"... это фича"

Есть маленький нюанс - вверх «ползет» только активная закладка - и она м.б. только одна.

Суть сценария использования закладок:

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

В итоге, когда много народу сделало коммиты, все слилось и готово к публикации - метка текущей версии будет аккуратно на самом последнем коммите.

Остается только создать создать новую закладку с номером последней версии - и вперед! При этом метка публикуемой версии «остановится».

anonymous
()
Ответ на: "это фича" от anonymous

Всё описанное вами не противоречит сказанному мной: hg update не должен перемещать закладку до головы текущей ветки.

Sorcerer ★★★★★
()
Ответ на: комментарий от Sorcerer

Всё описанное вами не противоречит сказанному мной: hg update не должен перемещать закладку до головы текущей ветки.

Только что проверил - update никак не влияет - закладка всегда остается на последнем (по очередности) коммите соответствующей ветки (в которой ее создали). При смене ветки, закладка, ест-но, тоже никуда не перемещается. Перемещение происходит только при новом коммите в соответствующей ветке.

anonymous
()
Ответ на: комментарий от anonymous

Что вы проверили-то? Если вы и так в голове ветки, то update естественно ничего не изменит. А вот вы сделайте закладку, потом получите через pull новые ревизии в этой ветке, потом выполните update.

Sorcerer ★★★★★
()
Ответ на: комментарий от waker

это особенность hg. этот мусор считается важной частью истории

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

Puzan ★★★★★
()
Ответ на: комментарий от Puzan

ну для меня это тоже одна из причин любить гит. к сожалению, на работе только hg :)

waker ★★★★★
()
Ответ на: комментарий от Puzan

Мы для целей засирания держим отдельный репозиторий, который синхронизируется с основным (забирает из основного все изменения).

Sorcerer ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.