Доступен (https://www.mercurial-scm.org/wiki/Release4.1) релиз распределённой системы управления версиями Mercurial 4.1 (https://www.mercurial-scm.org). Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих Mercurial, можно выделить следующие: Mozilla (https://hg.mozilla.org/), OpenOffice.org, OpenSolaris, NetBeans (http://hg.netbeans.org/main), OpenJDK (http://hg.openjdk.java.net/), Nginx (http://hg.nginx.org/nginx.org), Xine (https://anonscm.debian.org/hg/xine-lib/xine-lib/) и W3C.Основные изменения (https://www.mercurial-scm.org/wiki/WhatsNew#Mercurial_4.1_.2...):
- Представлен новый расширяемый API для подключения движков сжатия данных, позволяющий создавать расширения с поддержкой новых форматов сжатия;- В основной состав включен новый движок сжатия zstd, который собирается и используется по умолчанию во многих командах при работе поверх HTTP, если клиент и сервер поддерживают данный движок. Использование zstd позволяет на 60% снизить нагрузку на CPU на стороне сервера при выполнении операций, подобных "hg bundle".
- По умолчанию для опции "--profile" задействована новая статистическая система профилирвания, снижающая накладные расходы и выдающая более точные результаты, чем встроенный в Python профилировщик cProfile;
- Добавлена экспериментальная поддержка дополнительных возможностей из git-diff;- Реализована экспериментальная команда "hg debugupgraderepo", позволяющая на месте обновить рерозиторий до самой свежей версии формата хранилища;
- Значительно увеличена производительность чтения отдельных записей revlog, что положительно сказалось на скорости сканирования изменений в больших репозиториях;
- В два раза ускорена работа алгоритма определения различий содержимого, что привело к ускорению выполнения операций записи в репозиторий, таких как "hg commit".
URL: https://www.mercurial-scm.org/wiki/Release4.1
Новость: https://www.opennet.ru/opennews/art.shtml?num=45988
> Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си)читеры.
До numpy им ещё очень далеко. Вот где настоящее читерство.
>> Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си)
> читеры.Питон не тормозит. Же. https://www.mercurial-scm.org/wiki/PyPyPlan
> Питон не тормозит. Же. https://www.mercurial-scm.org/wiki/PyPyPlanФлопсов и RAM не бывает слишком много, но бывает достаточно.
что меня приятно поразило в Mercurial, так это возможность посмотреть что там в репозитории ДО pull'a. Мне этого иногда в git'e не хватает
А чем git fetch не угодил?
А разве git fetch -- это не оно?
Нет, не оно. Но отчасти заменит.
Дык а в чём проблема? `git fetch`-нул и сравнивай себе спокойно `git diff mybranch..origin/mybranch`. ТС говорит о предпросмотре изменений -- для того, чтобы что-то посмотреть, это надо сначала стянуть (fetch) и потом сравнить (diff). Всё логично, по мне.
Тут остается телепатировать, что имелось ввиду в оригинале. Я подумал, что он про hg incoming
Лучше log, а не diff.нужно так: git fetch; git log mybranch..origin/mybranch
В отличии от hg, в гите git log ..orgin/branch - намного функциональнее, и помогает в куче других случаев, как то при подготовке к мержу, ребейзу .
> > А разве git fetch -- это не оно?
> Нет, не оно.не ври!
git push
git fetch
git mergeэто ровно оно!
а ещё вот тебе парочка комманд на изучение:
git pull --ff-only
и
git pull --rebase
> что меня приятно поразило в Mercurial, так это возможность посмотреть что там
> в репозитории ДО pull'a. Мне этого иногда в git'e не хватаетpull вообще инвазивная слишком команда, надо избегать.
то что ты написал, делается git fetch; git log ..origin/mybranch . И этот подход более общий, ты можешь сделать git log ..vasya_github/mybranch или git log ..microsoftvcs/mybranch-fix-by-Nadella
Давайте разведём ветку конструктивного холиср0ча между сабжем и его основным конкурентом. Просто хочется знать о каких либо преимуществах одного над другим, пусть даже о мелких.
Неистово плюсую. Самому мне всё равно лениво искать профиты меркуриала в сравнении с гитом. Поэтому я громогласно заявляю -- МЕРКУРИАЛ НЕНУЖОН (и жду фанбоев, которые меня переубеждать сейчас начнут).
Поддерживаю. Даже если бы у него и были какие-то плюсы, сообщество выбрало git.
> Поддерживаю. Даже если бы у него и были какие-то плюсы, сообщество выбрало
> git.Не только сообщества разрабатывают софт.
Сообщество не "выбирало", оно как стадо подсело на то что дали в красивой обёртке.
Тут просто сработало то, что гит "раскрутили" быстрее: запили довольно удобный Github, ядро линуха лежит в гите и др.
И почему то мало кто при этом смотрел на объективные вещи: удобство использования, понятные команды, кривая обучения, работа под разными операционками (оригинальный git долгое время вообще не работал под Windows).
И все эти холивары Git vs Mercurial продолжаются потому, что нет среди них однозначного победителя по всем пунктам. Git раскрученный и много разработчиков его знает, есть популярный Github. Но зато Mercurial более удобный, расширяемый, и по моему имеет даже больше возможностей чем Git.
Спасибо, выразили все мои мысли разом.
> оригинальный git долгое время вообще не работал под Windowsи кому от этого было плохо? тем кто пишет под Windows? и что из этого? сами виноваты (насильно писать под Windows их не заставляли -- и работу тоже могли себе найти любую другой :))
> И все эти холивары Git vs Mercurial продолжаются потому, что нет среди них однозначного победителя по всем пунктам
нет. однозначный победитель есть..
а холивары продолжаются только лишь благодаря тому что одним людям бывает скучновато (пользователям git). а другим людям не хватает мозгов понять что нужно один раз выучить git и больше не страдать хернёй. выучить по нормальному, а не слегка!
> Но зато Mercurial более удобный
нет. не более удобный. удобный только для тех кто привык к Mercurial (а для того кто привык к SVN -- кажется что и SVN удобнее)
> расширяемый
расширяемость ради расширяемости -- не нужна. git делает своё дело хорошо (и да -- расширения для него тоже есть -- хоть и бесполезные по больей части)
> и по моему имеет даже больше возможностей чем Git
только не известно каких.. да? :-)
> тем кто пишет под Windows? и что из этого? сами виноватыКакое то у вас детское суждение. Можно подумать, что весь мир вертится вокруг линукса, а Windows и разработчики использующие его - это маргиналы, на которых не стоит обращать внимание.
Линус, когда пилил Git, явно не планировал делать его решением подходящим для всех. Просто Linux-у для хранения исходников ядра запретили использовать на халяву платное решение (BitKeeper). Вот Линус и запилил Git на коленке, из кучи разных утилит и языков программирования. При этом он пилил не VCS, а систему управления базой данных VCS (чем по сути и является Git). Т.е. git сам по себе - это довольно низкоуровневая штука (что не удивительно, ведь Линус, как разработчик ядра, имеет хороший опыт создания низкоуровневых систем). Предполагалось, что поверх git-а будут создавать отдельные фронтенды, и несколько специализированных даже было создано. Но как то всё пошло не так, и git получил распространение в том виде, в каком он есть - с кучек низкоуровневых, не простых и опасных операций, с не очень адекватным для целей простого программиста CLI.
С другой стороны есть Mercurial, который изначально разрабатывался с идей об его удобном и простом использовании именно как VCS, с которой непосредственно будут работать пользователи без всяких дополнительных фронтендов. Поэтому у них и более адекватный и простой в изучении CLI.
> Можно подумать, что весь мир вертится вокруг линукса, а Windows и разработчики использующие его - это маргиналы, на которых не стоит обращать внимание.всё верно: весь прогрессивный мир крутится вокруг Linux, BSD, и open source систем..
можете даже посмотреть на статистику "1% пользователей Linux" -- и подумать кто именно находится в 99% , а кто находится в остальных 1%.
прикладные разработчики-под-Windows -- не мергиналы разумеется -- а просто нейтральный БИОМАТЕРИАЛ. почти ни какого эффекта на прогресс-и-развите-технологий они совершенно не оказывают.
какой смысл обращать внимание на разработчиков-под-Windows -- совершенно не ясно. отдачи почти ни какой нет
> Какое то у вас детское суждение.
а у вас смотрю суждение -- статное и взрослое. ага! как же!
просто пытетесь оправдать свою трату времени, вот и всё
> Сообщество не "выбирало", оно как стадо подсело на то что дали в
> красивой обёртке.Все проще. Git сделан программистами для программистов, для отследивания версий, а не чтобы на питоне. А потом оказалось что питон не тормозит и все героически ускоряют, опять в два раза. А гит сразу нормально работал, чем программисты от питонистов и отличаются.
> Тут просто сработало то, что гит "раскрутили" быстрее: запили довольно удобный Github,
> ядро линуха лежит в гите и др.То-есть, сообщество вокруг ядра Linux вполне влияет на экосистему вокруг. Это толпа сильных разработчиков. С ними считаются, в отличие от.
> И почему то мало кто при этом смотрел на объективные вещи: удобство
> использования, понятные команды, кривая обучения,Как раз с этим у гита все прекрасно. Но вот правда для программистов которые *nix-like подходы предпочитают, желательно распределенно и опенсорсно.
> работа под разными операционками (оригинальный git долгое время вообще не работал под Windows).
Сейчас до очень многих програмеров дошло что под виндой многие вещи делаются неудобно и криво. Да что там, вьюжлстудия C99 не умеет до сих пор. А дотнетчики могут идти на свой codeplex и делать там что им угодно. На них и их поползновения всем просто пофиг. Это не экосистема разработчиков. Не сложилось.
> И все эти холивары Git vs Mercurial продолжаются потому, что нет среди
> них однозначного победителя по всем пунктам.По-моему победитель однозначен, а все эти оправдания и отмазки виндового неудачника только подкрепляют картину того где создается будущее в эти дни.
Для сообщества лучше гит.Для корпораций - в некоторых аспектах меркуриал.
Тупняк какой-то. Выбирают конкретные разработчики, а не "сообщество" или "корпорации". Если мне удобен меркуриал, то мне он удобен независимо от того, для кого я делаю проект. И так же с гитом.
я так понимаю, все зависит от процессов, которые workflowт.е. в разных ситуациях одному и тому же разработчику может быть более удобен то git, то mercurial.
просто в в обычном opensource, который строится на сообществе - более удобен git. но при работе в некоторых компаниях mercurial может оказаться более подходящим решением. повторюсь, всё это справедливо даже для одного и того же разработчика.
И какие же, прости госспади, волшебные workflow меркуриал поддерживает?http://nvie.com/posts/a-successful-git-branching-model/ можно и нужно применять хоть в гите, хоть в hg. Но hg не нужен, да. Пока не доказано обратное, ибо зачем плодить сущности.
Тыщи дистрибутивов линукса значит нужны, а меркуриал не нужен.
Приходишь так в сообщество, смотришь а там… у всех меркуриал - и ты им так: «Всё парни, с завтрашнего дня только git, я сказал!» :)зы. был тут у нас один гитовец, ничего, перековали на svn :D :D :D
Что-то у тебя ответ не связан с вопросом. В огороде бузина...В компании можете использовать хоть черта лысого, и конечно, желательно, что бы всё было единообразно. От ваших процессов зависит только эффективность работы компании. Хотя и тут, в случае с svn, гит позволяет использовать git-svn. Так что не велика потеря.
А на самом деле наоборот: кто-то разрабатывает себе в меркуриал. Вот начинают проходить мимо люди, хотят помочь, но тут облом: меркуриал. И начинают давить, переходи на гит. И в итоге некоторые сдаются.
> Вот начинают проходить мимо люди, хотят помочь, но тут облом: меркуриал.Вот и пускай проходят себе мимо. Если они не в состоянии осилить меркуриал хотя бы в объёме clone/commit/push/pull/update (практически всё тоже самое что и в git), то я сомневаюсь, что их помощь будет сильно полезной.
> Вот и пускай проходят себе мимо.Что характерно, именно это обычно и происходит. Вот прямо идешь в новость и смотришь список мега проектов.
Давай глянем? Мозилла? Куча неудачников по которым плачет могила. У них движок сгнил а новый они так и не сделали. Пользователей достало и они ушли на хром. И дальше уйдут. Кстати гугл в отличие от этих дурней git использует. Техническое превосходство - так уж во всем.
Опенсолярис? OpenOfficeOrg? NetBeans? OpenJDK? Xine? Это успех, их там позаваливало коммитами.
Кто там еще живой? Nginx? Ну это bsd-шные проприетарщики. Их дружественность к разработчикам легко оценить. По количеству разработчиков и коммитеров, хотя проще просто попробовать модуль написать. Сразу познаешь все прелести и дружелюбие.
> и жду фанбоев, которые меня переубеждать сейчас начнутсообществу пофиг. сообщество юзает и то, и то.
мне тоже пофиг. я тоже юзаю и то, и то, и выбирать что-то одно и клеить его на флаг - не собираюсь
Поддерживаю.
В hg нет веток. На этом можно и закончить. То, что там называю ветками, это какая-то хня.Но я не закончу. В changeset в меркуриале попадает название "ветки". Т.е. буквально: "default" или "myC00lBran4". Это потом всплывает при мерже в репозитарий, где ветки "myC00lBran4" нет.
Хватит?
Разупорись, будь добр
По существу будет аргументация? Или "нам наплевать на кривость и косяки, лишь бы гламурный TortoiseHg под десяточкой запускать, а не непонятную консоль в гите"
Кратко:
1) В меркуриал таки ветки, в git - указатели. Это по большому счету, вопрос терминологии.
2) В меркуриал как раз таки ветки "есть везде". 3) То, что в changeset есть название ветки, кому-то даже удобнейТо, что в Mercurial превыкли называть веткой - это heavybranch. А бошки, что в гите, что в меркуриал.
Ну, и первый гугл: https://www.mercurial-scm.org/wiki/GitConcepts
>1согласен, это вопрос терминологии. Для меня ветки hg не узабельны, в том числе и из-за п.2
>2
Неиллюзорные проблемы мержа в свою репу я испытываю в hg. Дело касается реально больших изменений, когда в стороннем репе используются свои ветки. Поэтому мне это не удобно, да
> В hg нет веток.Вы это о чём? Вот как раз в гите нет настоящих веток, то что там называется веткой - это просто локальная именованная ссылка на один из top-овых коммитов в дереве, которая не пушится во внешнюю репу.
В меркуриале есть аналог таких вот именованных ссылок, и они тоже работают только в локальном репазитории и не уходят во внешние репы.
>> В hg нет веток.
> Вы это о чём? Вот как раз в гите нет настоящих веток,
> то что там называется веткой - это просто локальная именованная ссылка
> на один из top-овых коммитов в дереве, которая не пушится во
> внешнюю репу.
> В меркуриале есть аналог таких вот именованных ссылок, и они тоже работают
> только в локальном репазитории и не уходят во внешние репы.Вы зря мешаете тёплое с мягким. Именованная ссылка --- это одно. Передача именнованных ссылок в другой репозиторий --- это другое. А branch --- это узел в графе коммитов у которого два потомка. И в hg это, наверное, должно быть так же.
> А branch ---
> это узел в графе коммитов у которого два потомка. И в
> hg это, наверное, должно быть так же.Хм, branch - это так то ветка, а не узел (node), поэтому ваше определение как то не очень подходит.
> Хм, branch - это так то ветка, а не узел (node), поэтому ваше определение как то не очень подходит.Хорошо. Любой путь к листу в графе коммитов. А узел в графе коммитов у которого два потомка --- это branch point. Так лучше?
Т.е. даже первую страницу самого простого туториала по ртути ты прочитать не осилил дальше заголовка? Потому что там обычно во втором абзаце написано, что то, что в гите называется ветками, в меркуриал называется букмарк, что намного правильней.
Ты так говоришь, как будто этими букмарками пользовался. Или теоретик-читатель мануалов? Простите, но букмарки это инородно даже hg, и неюзабельно соответственно. И это совсем не то, что ветки в гите, а "аналог". Китайский, ага
Различия не настолько принципиальны, чтобы быть причиной выбора, поэтому проще взять то, что более распространено - то есть гит.
Pro Mercurial* Rename/copy tracking
* Phases (мешает переписать опубликованную историю)
* ChangesetEvolution (что-то вроде распределённого reflogа).
* Revsets
* Продуманные UI и руководство
* Extensions на любой вкус (hggit, hgsubversion, largefiles, тысячи их)
* Graft (аналог cherrypick) пишет id предка в метаданные, а merge его учитываетPro Git
* Octopus merge
* Staging area (я не пользуюсь)
* rerere (говорят, полезно, не пользовался)
> Pro Mercurial
> * Продуманные UI и руководство
> Pro Git
> * Staging area (я не пользуюсь)``Git has something called the "staging area" or "index".``
:-O Матёро!
> ``Git has something called the "staging area" or "index".``
> :-O Матёро!што
#>> Pro Git
#>> * Staging area (я не пользуюсь)
>> ``Git has something called the "staging area" or "index".``
>> :-O Матёро!
> штоНе пользоваться индексом *и* пользоваться git-ом -- это авангардненько-артхаусненько, это не для слабаков, это надо очень напрячься, чтоб суметь. Мастер!
> Не пользоваться индексом *и* пользоваться git-ом -- это авангардненько-артхаусненько, это не для слабаков, это надо очень напрячься, чтоб суметь. Мастер!Я понимаю, что там где-то под капотом IDEA, возможно, и вызывает git-add, но сам я — нет, т.к. незачем. А коль понадобится раз в полгода закоммитить правки в файле через одну, ну, скомандую git commit --patch, делов-то. Ну то есть понятно, что диды с торвольцом завещали сначала добавлять правки в индекс, потом коммититься и всё такое, но с каких пор подумать своей головой стало ракетной наукой?
Есть репозиторий на Mercurial, в котором по какому-то стечению обстоятельств создалась вторая "головная" ветвь в бранче default, состоящая из одного коммита. В битбакете оно светится как "main branch (2 heads)". Теперь это дело мешает жить, правки из этого коммита уже не актуальны (соответственно вмержить в основную ветвь их нельзя), но и удалить этот второй мастер не получается.>> hg strip -r
удаляет локально лишний коммит и его бранч, но при pull он стягивается с сервера повторно
>> hg backout -r
abort: cannot backout change that is not an ancestor
Анон, вмёрж его и сделай revert но его номеру, не мучайся
Стрипните лишнюю голову в вебморде bitbucket
вот бы на этой коммерческой системе запустить репозиторий винды в 250 гб и 3,5 млн файлов.
Конечно, интересно. Но тут, мне кажется, проблема не в системе контроля версий, а "что-то в этой репе не так".
Ну можно в качестве примера взять опыт Facebook, у них конечно не 250Гб наверное (3 года назад в git копии у них было 54Гб) - https://code.facebook.com/posts/218678814984400/scaling-merc.../ . Они решили свои проблемы со скоростью как то более правильно - сделали какие то патчи для меркуриал, написали расширение для него специальное, которое вероятно теперь доступно для всех.
Майкрософт же приняло решение не трогать "бяку", и навертеть оптимизаций сбоку от Git-а. Запилили виртуальную FS-ку, и изменили серверную версию Git, что бы она поддерживала эту FS. В результате их решение работает только у них.
всем кто спеной у рта доказывает что гит ваше/наше все а ртуть *авн0 и считает что в в голове у вас опилки^Wсерое вещество вот вам немного чтения как пример того что может "гогно"https://groups.google.com/forum/#!topic/mozilla.dev.version-...
а еще погуглите столько времени занимает git diff в склонированой репке ядра
Xine 5 лет как закрылся, нарколыги!
> Xine 5 лет как закрылся, нарколыги!--Св-----, они убили xine. Опять.
Как закрылся?
Лучшая Version Control System.Bazaar гибче, Mercurial продуманней.
> Bazaar гибче, Mercurial продуманней.А git еще и работает к тому же. Не тормозит. И сделан для програмеров а не гламурных тупиц в десятке.
Вопрос знатокам hg: зачем в практике сопровождения hg-based-проектов частенько рвут историю на разные репозитории?Приблизительно как здесь:
https://gmplib.org/repo/
(gmp, gmp-???, ... )
> Вопрос знатокам hg: зачем в практике сопровождения hg-based-проектов частенько рвут историю
> на разные репозитории?Может как раз таким образом решают проблему больших репазиториев? Если они не делают бакпорт фиксов и каких то фичей в старые версии, то нет какого то особого резона тащить хвост из коммитов от старой версии, если их там 100500 и занимают дофига места. Тоже самое можно делать и на Git - это не какая то особенность присущая меркруиал репазиториям.
> Может как раз таким образом решают проблему больших репазиториев?В это не верится: история не обрезается снизу (старая), а подрезается сверху; экономии места нет, даже наоборот --- у бОльших репозиториев возможность переиспользовать идентичные блоки выше. Какие-то пляски с долгоподдерживаемыми ветками (как-бы-ветками?)? Но зачем? Хрень какая-то --- проблемы вижу, рационального зерна не вижу.
> В это не верится: история не обрезается снизу (старая), а подрезается сверху;Ну тогда фиг знает, это видимо какая то непонятная задумка авторов этой либы. Я сам такого нигде не встречал ещё.
>> В это не верится: история не обрезается снизу (старая), а подрезается сверху;
> Ну тогда фиг знает, это видимо какая то непонятная задумка авторов этой
> либы. Я сам такого нигде не встречал ещё.А это не специфично для gmp. Но в hg-репозиториях я такое несколько раз встречал.
Ладно, отнесем к разряду "какая-то хрень".
> А это не специфично для gmp. Но в hg-репозиториях я такое несколько
> раз встречал.
> Ладно, отнесем к разряду "какая-то хрень".Как вариант - это просто один и тот же реп, склонированный на сервере в разные папки и переключенный на соответствующие бранчи, что бы можно было с ними параллельно работать. Никакого доп. места на диске для хранения истории оно не занимает, т.к. она "клонируется" как хард-линка. Точно так же можно сделать и локально, если нужно параллельно работать с разными бранчами.
Хотя в случае GMP смущает что набор тегов в этих "репах" всё таки отличается.