Mercurial 3.8

Скоро будет, тот самый ~mercurial-ppa пилится прям щас.

Это «довольно сложное ПО» облегчает процесс разработки.

Я бы рад, чтобы у нас был такой процесс, который бы могло облегчить какое-то ПО третьих лиц, но увы и ах.

Для не-людей зачем вообще удалять мусор?

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

Если вы завязали свой процесс на уникальную возможность Git - естественно.

Удалять ненужное — это уникальная возможность Git? Но даже если и так, насколько я знаком с историей (я сюда пришёл работать позже), процесс сформировался ещё до того, как Git был написан. Началось всё ещё во времена, когда CVS «починил» RCS, если ты понимаешь, о чём я.

Я бы рад, чтобы у нас был такой процесс, который бы могло облегчить какое-то ПО третьих лиц, но увы и ах.

Это многое объясняет.

Удалять ненужное — это уникальная возможность Git?

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

Ок. На этом этапе я окончательно потерял понимание предназначения бранчей в Hg. Для Гита в своё время был написан небезызвестный «A successful Git branching model». Есть ли подобное эссе для Mercurial?

Что касается «редактирования истории», это какой-то философский вопрос, обсуждать который не имеет смысла: есть производственная необходимость и она превыше. Но основную идею хотелось бы всё же понять. В процессе неизбежно будет накапливаться какое-то количество мусора — файлы, добавленные по ошибке, код, который потерял актуальность быстрее, чем попал в релиз (если мы говорим о софте) и тому подобное. Хранить эту историю бессмысленно, она не имеет исторической ценности. Как решается эта неизбежная проблема в Hg?

Понравилось, что в логе теперь видно, где пропущены коммиты:

  $ hg log -G a
  o  changeset:   4:50b9b36e9c5d
  |  tag:         tip
  |  user:        test
  |  date:        Thu Jan 01 00:00:00 1970 +0000
  |  summary:     content3
  |
  @  changeset:   3:15b2327059e5
  :  user:        test
  :  date:        Thu Jan 01 00:00:00 1970 +0000
  :  summary:     content2
  :
  o  changeset:   0:ae0a3c9f9e95
     user:        test
     date:        Thu Jan 01 00:00:00 1970 +0000
     summary:     content1

Что такое анонимный бранч? Чем анонимный бранч отличается от неанонимного и от букмарки? Публикуются ли анонимные бранчи и букмарки в центральном репозитории и видны ли они оттуда всем? Возможен ли гранулярный контроль доступа (ro/rw/wo/deny) на уровне бранчей или аналогичном? Что значит «закруть барнч»? Как именно он после этого себя ведёт, виден ли в системе? Можно ли удалить всю историю, начиная с определённой даты? У меня есть репозитории размером >400Gb, начатые ещё в конце 90х. Эти данные представляют археологический интерес, но для работы нужен только сабсет данных за последний месяц с историей (тысячи коммитов vs чуть больше миллиона).

Не забываем про Emacs и magit. Есть люди, которые в нем сидят. Для git-a самое оно. Для hg есть аналоги, но слабее. Так что как Emacs-юзеру мне git удобнее.

Это многое объясняет.

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

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

Ugh. RTFM: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Я понял, что у вас что-то необычное с тяжелым историческим багажом.

В mercurial можно удалять локальные / удалённые ветки, как в git?

hg bookmark --delete <bookmark name>
hg push --bookmark <bookmark name>

нет

Примерно так, но несколько сложнее. Поменялось больше половины файла? Отрубаем угадывание. Большая разница между коммитами? Отрубаем угадывание. Про то, что история скопированного файла начинается с момента копирования, я вообще молчу.

Вообще история, которая зависит от ключей команды diff, выглядит протёкшей абстракцией, если не абсурдом.

Есть ли подобное эссе для Mercurial?

не нужно, в hg успешна каждая первая branching model.

в выводе hg branch

Спасибо! Это, кажется, именно то, что я искал.

Я понял, что у вас что-то необычное с тяжелым историческим багажом.

Так и есть. Когда-то даже я смогу написать об этом увлекательную статью.

Это возмутительная ложь. К тому же эссе есть.

Для Гита в своё время был написан небезызвестный «A successful Git branching model».

на всякий случай, если ты не вкурсе: это очень спорный гайд, далеко не все согласны с такой моделью, даже в кор гит коммьюнити.

Есть ли подобное эссе для Mercurial?

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

Что касается «редактирования истории», это какой-то философский вопрос, обсуждать который не имеет смысла: есть производственная необходимость и она превыше.

в разработке ПО в таком случае 95% всего можно отнести к филосовским вопросам. редактируйте себе свою историю, мне то что. только когда прострелите себе обе ноги, не войте на форумах про плохие инструменты. ваша «производственная необходимость» — надуманна и решается другими способами, даже и без изменения процесса.

В процессе неизбежно будет накапливаться какое-то количество мусора — файлы, добавленные по ошибке, код, который потерял актуальность быстрее, чем попал в релиз (если мы говорим о софте) и тому подобное. Хранить эту историю бессмысленно, она не имеет исторической ценности. Как решается эта неизбежная проблема в Hg?

вы какой-то другой анонимус или это просто другой пример а не то про что мы изначально говорили? энивей, хранить эту историю можно и нужно — на то она и история, она показывает как изменялся проект и позволяет вернуть старое состояния. если вам эта история не нужна — пожалуйста, удаляйте на здоровье. только вы тогда не понимаете что такое системы контроля версий и зачем они нужны.

Что такое анонимный бранч? Чем анонимный бранч отличается от неанонимного и от букмарки? Публикуются ли анонимные бранчи и букмарки в центральном репозитории и видны ли они оттуда всем? Возможен ли гранулярный контроль доступа (ro/rw/wo/deny) на уровне бранчей или аналогичном? Что значит «закруть барнч»? Как именно он после этого себя ведёт, виден ли в системе?

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

Можно ли удалить всю историю, начиная с определённой даты?

У меня есть репозитории размером >400Gb, начатые ещё в конце 90х. Эти данные представляют археологический интерес, но для работы нужен только сабсет данных за последний месяц с историей (тысячи коммитов vs чуть больше миллиона).

это в гите надо убер костыли строить и историю удалять, чтобы он не сдох на таких обьемах. и терпеть вечные тормоза и гарбедж коллекшн. серьезно, попробуйте меркуриал, расширения от фб специально предназначены для таких реп и работают отлично. в частности, смотрите на remotefilelog (ограничивает локальную историю), sparse checkout (ограничиват чекаут одним или несколькими сабдиректориями) и fsmonitor (watchman) про который в новости написано. жизнь наладится, у меня репо, скажем так, чуть меньше по размеру и существенно больше по истории, все операции < 1с, базовый чекаут с которым я в основном работаю — меньше 200Mb, только тот код и немного свежей истории с которой я реально работаю. а еще есть hgsql если ваша серверная ферма не справляется с рейтом изменений и нужно нормальный реплицируемый транзакционный бекенд. https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/remotefilelog

automv

В git аналогичный функционал работает давно изкоробки. Рад что и здесь он теперь будет

Я так понимаю, что моя настойчивость вызывает только раздражение. Не стоит воспринимать мои слова как нападки на Mercurial или на вас лично, у меня не было такой цели. Прошу простить, профессиональная привычка. В любом случае, спасибо за потраченное время. Основываясь на этом эссе я сделал два вывода:

1. Mercurial не подходит для решения моей задачи именно из-за того, что полнота, целостность и непрерывность истории изменений поставлены во главу угла. Моя задача — не являющаяся разработкой ПО, но тем не менее предполагающая работу с большими объёмами текстовой информации — как раз требует возможность удаления ненужных частей пост-фактум. Богатые возможности по написанию плагинов делают его очень привлекательным, но в остальном мы будем постоянно плыть против течения.

2. Mercurial — лучший инструмент из имеющихся для тех случаев, когда история эволюции данных — e.g., текста, кода — является главной ценностью. Мои коллеги сейчас решают эту задачу невообразимым монстром на Java + Fortran (не спрашивай). Думаю, это избавит их от головной боли.

На этом благодарю за помощь.

В git аналогичный функционал работает давно изкоробки

Mercurial 3.8 (комментарий)

вопрос такой: а тебе нужны именно бранчи? потому что скорее всего тебя нужны букмарки, и уже есть ремоут букмарки.

HG «интуитивно понятный», говорили они. У него общепринятая терминология, говорили они.

У нас делаются scratch-репозитории, годные изменения из которых пуллятся в чистовые репозитории, а scratch-и тупо прибиваются через некоторое время.

Пользователи Mercurial'а еще не попали в ад, но уже начинают страдать.

причем здесь add/remove? Я и в git это явно делаю и тем не менее он угадывает, если удалить один и тот же(или похожий, тогда пишет проценты схожести) и добавить файл под другим именем

Не знаю как в mercurial, но в git изменение истории не пройдет безболезненно - клиенты уже не смогут сделать git pull и получить обновления без дополнительных телодвижений, придется делать что-то вида git fetch && git reset --hard origin/branch_name

И это даже хорошо. Потому что в git можно стрелять себе в ногу(--force) если ты знаешь, зачем оно нужно

причем здесь add/remove?

То, что ты назвал «аналогичным функционалом», который «теперь будет» - это addremove в другой обертке. Который есть уже лет 7-8.

У него общепринятая терминология, говорили они.

Есть новички, которые кроме git, ничего не видели - им кажется общепринятой терминология git. Это естественно.

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

в ртути аналогично. только в меркуриале это не является культурной нормой.

«Общепринятой» является терминология из svn.

В git всего два основных вида объекта - коммит и бранч. Плюс тэг как плюшка.

Все три термина и их семантика известны со времён subversion. Никаких, прости господи, «букмарков» и никакой мистической разницы между локальными и удалёнными «букмарками».

Единственное, что действительно «контр-интутивно» в git из самых базовый вещей - это «двухфазный коммит» через staging area. Пересаживать svn-утку на git - вопрос установки ToroiseGit.

«Общепринятой» является терминология из svn.

Понятие branch из git ей не отвечает.

известны со времён subversion

%)

Понятие branch из git ей не отвечает.

И в чём же мистическая разница?

известны со времён subversion

%)

Вот только не надо тут rcs на diff'ах разводить. Все эти cvs страшно далеки были от народа.

В git всего два основных вида объекта - коммит и бранч. Плюс тэг как плюшка.

Да-да, поэтому количество гитоутилит сильно превышает 100, включая всякие паковщики-перепаковщики, да и сборщик мусора, заодно.

Баттхёрт неосилятора? Так и запишем.

И в чём же мистическая разница?

Ну хотя бы тем, что «бранчи» в git растут в прошлое, а не в будущее

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

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

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

Ты как одну звезду получил-то? У модераторов насосал?

в меркуриале это не является культурной нормой

Так и для git в нормальных книгах упоминается что есть такие вещи как rebase(который надо знать когда применять) и filter-branch(который вообще нужен ооочень-редко) и то, что регулярно их использовать на remote-ветках - это далеко не good practice

Ты как одну звезду получил-то? У модераторов насосал?

Ну с тобой всё ясно.

З.Ы.: http://www.lorquotes.ru/view-quote.php?id=4

количество гитоутилит сильно превышает 100

А тебя прямо из под палки заставляют ими пользоваться? В секции Advanced в книге Pro Git вообще упоминается как поверх git навернуть произвольное объектное хранилище. А теперь внимание вопрос - нужно ли это знать для того чтобы полноценно пользоваться git-ом как DVCS? Ответ - нет.

И в чём же мистическая разница?

Тебе именно мистическая? Тогда ХЗ. Принципиальная - том, что имя бранча не является частью истории.

Ты серьёзно? И что же тут «принципиального»?

А теперь внимание вопрос - нужно ли это знать для того чтобы полноценно пользоваться git-ом как DVCS? Ответ - нет.

С этим не поспоришь. Чтобы пользоваться практически любой DVCS, вообще не обязательно разбираться в её кишках. Достаточно лишь знать две-три команды, а всё остальное гуглить при надобности.

Этим большая часть специалистов по системам контроля версий и пользуются, заявляя, что они все из себя осиляторы. А потом ещё обижаются на что-то :)

Вопрос: в hg эта информация считается слишком важной, чтобы не удалять или в hg в принципе другой подход и ветка --- вещь более тяжеловесная и долгоживущая?

в хг ветки завязаны друг на друга, и удалить ветку, от которой отходит другая ветка — нельзя.

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

а 500 коммитов в хг это не очень сильно?

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

ерунда. я пользуюсь обоими системами ежедневно, и мне git во всем больше нравится. плевать на авторитеты.

очень самонадеянно. расскажешь об этом Андрею Александреску, или может Дженсу Аксбо, или Крису Мейсону, ммм?

давай ты сначала предоставишь пруф, что эта троица имеет какое-то отношение к работе над hg в фейсбуке.

ничем она не устарела, или пруф в студию

пруф того, что информация устарела? посмотри на дату статейки. ей 2 года, а события в статье произошли еще на пару лет раньше. ты думаешь, за эти прошедшие годы ничего не происходило? это твои проблемы.

В секции Advanced в книге Pro Git вообще упоминается как поверх git навернуть произвольное объектное хранилище. А теперь внимание вопрос - нужно ли это знать для того чтобы полноценно пользоваться git-ом как DVCS?

Ответ - да, потому что это объектное хранилище в интерфейсе гита протекает изо всех щелей. И не надо этих сказок про «достаточно выучить add, commit и push», потому что постоянно будут вопросы типа «ой я зделал fetch и какая-то хрень полезла как вернуть!!!» или «че ещё за detached head че эта ваще???» Пока не прочитаешь все сраные 700 страниц талмуджа, не сможешь этим марсианским трактором удовлетворительно пользоваться. Ну или можно быть stackoverflow-driven девелопером, щас все так делают, а хуле делать, если каждая вспомогательная хрень имеет интерфейс марсианского ядерного реактора и мануал на 700 страниц со своей особой терминологией? Жизнь-то одна.