Увидел свет (http://www.selenic.com/pipermail/mercurial/2011-November/040...) релиз распределенной системы управления версиями Mercurial 2.0 (http://mercurial.selenic.com). Версия 2.0 не отличается кардинальными изменениями, смена первой цифры является следствием принятых в проекте правил нумерации релизов (после версии 1.9 выходит не 1.10, а 2.0).
Ключевые изменения (http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.0_.28...):- Новая команда graft (http://www.selenic.com/mercurial/hg.1.html#graft), реализующая функциональность сходную с расширением transplant. Команда graft позволяет скопировать отдельные изменения из другой ветки без непосредственного слияния веток, что существенно упрощает выполнение таких операций как бэкпортирвоание изменений;
- В состав включено расширение largefiles (http://mercurial.selenic.com/wiki/LargefilesExtension) для работы с помещаемыми в репозиторий большими бинарными файлами, которые плохо сжимаются, не пересекаю...URL: http://www.selenic.com/pipermail/mercurial/2011-November/040...
Новость: https://www.opennet.ru/opennews/art.shtml?num=32211
молодцы! осталось исправить недароботку с хранением-и-использованием файловых имён (кодировкой)вобщем проект развиватся, рад за него! :-)
# p.s.: сам пользуюсь Git
ура! Mercurial реально самая лучшая мощная и простая DVCS, а в git приходится долго ломать голову, нет уверенности в инструментеа с Mercurial всегда уверен что все работает как надо и ты сможешь разобраться как пользоваться самыми сложными ее возможностями - факт, в git не так
минус - кодировка имен... были проблемы, подтверждаю
кто знает - как там дела обстоят - почему проблемы?
неужели там не UTF-8?
>а в git приходится долго ломать
> а с Mercurial всегда уверен что всеЗачитайте полный список автотренинговых мантр, пожалуйста? Ну, мож в мане иль на сайте уже есть?? А ликёро-водочный сегодня нарядов не прислал?...
Спорно что mercurial лучше git, git более прозрачный и понятный. Да и в mercurial очень неудобные бранчи, я бы даже сказал отвратительные.
Бранчи в mercurial такие же, как и в git. Более того, в mercurial есть 3 способа ветвления, а в git - только 2.
> Бранчи в mercurial такие же, как и в git. Более того, в mercurial есть 3 способа ветвления, а в git - только 2.И не один способ ветвления в mercurial не может сравниться по удобству и простате с бранчами из git. Работаю и с mercurial и с git. В git с ветвлениями проще получается.
да.. с простатой в git-e и правда получше.
Может простОте? Или вы реально имел в виду прост`ату?
Он не лучше, и не хуже. Он легче. Для людей кто впервые встречается с VCS, mecrurail это то что нужно. Ты не выстрелишь себе в ногу. Плюс в нем есть GUI и встроенный приличный web server и много еще другого. Одни замуты с users/ssh в git чего стоят.
> Одни замуты с users/ssh в git чего стоят.Зато в git можно синкать хоть разные диры между собой, хоть патч на флешке принести. Порой реально удобно. А в hg - ну знаете, админить еще один самобытный вебсервант не очень то и хотелось.
hg import для патча на флешке.
что подразумевается под разными дирами?
> что подразумевается под разными дирами?Вася работает в /home/vasya а петя - в /home/petya, допустим на 1 машине. Можно взять да засинхрить их. Для гита это совершенно нормально.
> Зато в git можно синкать хоть разные диры между собой, хоть патч на флешке принести. Порой реально удобно. А в hg - ну знаете, админить еще один самобытный вебсервант не очень то и хотелось.с добрым утром, в Mercurial тоже это можно делать, причем из TortoiseHG в GUI на любой ОС тыкай себе с чем синхронизоваться, хоть с флэшкой, а hg bundle в GUI и hg unbundle это еще лучше чем патчи, это равносильно hg pull/push, только на лошадях
веб сервер может быть как свой, как встроенный, так и любой, причем опять же из GUI one-click сервер и вот с тебя уже твой сосед качает
Mercurial очень простая и мощная DVCS, любые нападки с "git лучше он тото это" - просто из за неосведомленности
> Он не лучше, и не хуже. Он легче. Для людей кто впервые встречается с VCS, mecrurail это то что нужно. Ты не выстрелишь себе в ногу. Плюс в нем есть GUI и встроенный приличный web server и много еще другого. Одни замуты с users/ssh в git чего стоят.Для новичка, незнакомого с контролем версий git проще, благо есть куча полезных ресурсов по нему. С mercurial все так же но ресурсов меньше.
Выстрелить в ногу можно и с git и с mercurial. При чем с mercurial получается больнее.
Встроенный web server сомнительный плюс, так как новичкам он не нужен, только отвлекать будет. Хотя возможно кому-то полезно.
> Встроенный web server сомнительный плюс, так как новичкам он не нужен, только
> отвлекать будет. Хотя возможно кому-то полезно.кому-то??? ты можешь работать без центрального сервера без проблем и из GUI, один клик и с тебя качает сосед, причем он же в GUI, ничего не перелопачивая
GUI к Mercurial это отдельный момент, выше всяческих похвал
а один только GUI убивает удобства git-а, и то едва ли они естья пользовался долго и git и Mercurial - hg явно лучше, подтверждено на практике как своей так и многих других
Новичку не в коем случае нельзя знакомиться с системой контроля версий с GUI. Начинать всегда нужно с командной строки.> GUI к Mercurial это отдельный момент, выше всяческих похвал
а один только GUI убивает удобства git-а, и то едва ли они есть
Я вот не пользуюсь GUI не к одной системе контроля версий. Для программиста это неудобно и медленно.
> я пользовался долго и git и Mercurial - hg явно лучше, подтверждено на практике как своей так и многих других
А я пользовался мозгом и мне не важно что использовать, хоть git, хоть mercurial, хоть svn. Для главное достоинство git удобные бранчи, при работе над проектом нескольких программистов, необходимость в бранчах встает очень остро. А mercurial в этом плане не намного лучше svn. В mercurial просто другой подход к бранчеванию, не такой удобный как в git, но вполне оправданный и имеющий право на жизнь. Возможно вы просто имеете дело с разработкой такого ПО для которого mercurial хватает, у меня доже большую часть времени mercurial не вызывает нареканий, кроме тех редких случаев когда необходимо поддерживать сразу до 3 бранчей с постоянными между между ними.
>[оверквотинг удален]
> А я пользовался мозгом и мне не важно что использовать, хоть git,
> хоть mercurial, хоть svn. Для главное достоинство git удобные бранчи, при
> работе над проектом нескольких программистов, необходимость в бранчах встает очень остро.
> А mercurial в этом плане не намного лучше svn. В mercurial
> просто другой подход к бранчеванию, не такой удобный как в git,
> но вполне оправданный и имеющий право на жизнь. Возможно вы просто
> имеете дело с разработкой такого ПО для которого mercurial хватает, у
> меня доже большую часть времени mercurial не вызывает нареканий, кроме тех
> редких случаев когда необходимо поддерживать сразу до 3 бранчей с постоянными
> между между ними.Скажем так, в Mercurial есть как минимум mq, который представляет альтернативу как лёгким ветка Git'a, так и его stash; не прямой аналог, но конечный результат аналогичен. А там уж кому что удобнее использовать, конечно. :)
> Выстрелить в ногу можно и с git и с mercurial.Значит, всё в порядке -- вот и давайте порадуемся лучше, что выбор есть :)
Пользователям и разработчикам hg -- поздравления с релизом, и чтоб инструмент побольше помогал да поменьше на себя внимания требовал :)
Еще гит реально быстрый. В отличие от. Эффективно передает изменения по сети, но можно и хоть на флоппике патч принести. Как по мне - он симпатичнее этой странной кривоватой и тормознутой hg.
> бестрейit depends. Например вот так: http://draketo.de/proj/hg-vs-git-server/test-results.html
Что не так с патчами в hg?
>> бестрей
> it depends. Например вот так: http://draketo.de/proj/hg-vs-git-server/test-results.htmlАга, вот так :))). Для начала там нас встречает эпичная фраза:
-------------
> Assume for a moment, that you want to create the newest social web application,
> and you want to use an established distributed version tracking tool as data backend-------------
В переводе на русский: допустим мы хотим забить микроскопом гвоздь. Берем микроскоп одной фирмы и другой фирмы и смотрим насколько удобно е...ть по гвоздю! Меряем частоту ударов в минуту.
Что еще смешнее, оказывается что git-ом с настройками по умолчаниб к тому же лупится явно быстрее. Но конечно же, если результат не нравится - его можно подтормознуть! Заставив дергаться сборку мусора на каждый пшик. Так что угодно тормознуть можно, хренли.
Безусловно, если хочется показать крутость hg и зачмырить гит - это вариант, но какой же дебил на практике затормозит себе гит ручной пропиской таких параметров GC'у? Не говоря о том что использование системы контроля версий для "newest social web application" подразумевает что автору пора бы в дурку, при условии что это не будет сервис типа гитхаба, где такое еще можно понять.
> Что не так с патчами в hg?
Скорее, что так в git: уйма способов синхронизировать и объединять репы. Вплоть до синхры с репом в соседней дире.
Блин ... цитируя Филатова - "Зарядила как удод- что не слово то Федот!" - это про соседние диры
hg pull --update ../hg/other_dir/ чем не угодил ? или через ssh ? или hg bundle и опять-таки pull ? или hg serve и hg pull ...
Резюме - Чукча хэлп не читал и в руках не держал ....
> Блин ... цитируя Филатова - "Зарядила как удод- что не слово то
> Федот!" - это про соседние дирыА, то-есть возражений по поводу того что при _практическом_ использовании с дефолтными настройками хг в отличие от гита тормоз вы не имеете?
> Резюме - Чукча хэлп не читал и в руках не держал ....
Посмотрев на то как оно в разы сливает гиту на типовых операциях с репами исходников, а не какими-то больными на голову бэкэндами для вебни - я разумеется напер на изучение гита, а не этой странной хрени.
> А, то-есть возражений по поводу того что при _практическом_ использовании с дефолтными настройками хг в отличие от гита тормоз вы не имеете?prove it. у меня hg не тормозит. bzr медленный, да. а hg летает. ЧЯДНТ?
Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.Зачем их сравнивать? это две хорошие утилиты, и славо богу что есть какая то конкуренция и выбор.
> Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.Еще как трогается.
> Да git быстрее/навороченей, но готов поспорить что 70% из этого никогда не трогается.А 95% населения вообще идиоты и им вообще никакие гиты и меркуриалы не сдались :)
> приходится долго ломать голову, нет уверенности в инструментеСудя по количеству пользователей git и бурному росту гитхаба - дело все-таки не в бобине, а в том кто в кабине.
>> приходится долго ломать голову, нет уверенности в инструменте
> Судя по количеству пользователей git и бурному росту гитхаба - дело все-таки не в бобине, а в том кто в кабине.«миллион мух не может ошибаться»©
если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.не было pull request, вот и не смог. так что дело в github
>>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
>> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
> не было pull request, вот и не смог. так что дело в
> githubА еще у них раньше был интерфейс не красивый и цвета сайты были не подходящими к фазе луны.
Истинным популяризатором git был Линус. Так что если уж кого и винить в популярности git, то его, а не github.
>>>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
>>> bitbucket не смог сделать mercurial популярным. Так что дело в git, а не в github.
>> не было pull request, вот и не смог. так что дело в github
> А еще у них раньше был интерфейс не красивый и цвета сайты были не подходящими к фазе луны.Неа. Киллерфичей github являлась возможность одной кнопкой вмергать pull request. У bitbucket этого не было, т.к. они полагались на hg pull + hg merge + hg push. 3 действия против одного. Продолжать?
> «миллион мух не может ошибаться»©
> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.Наверное именно поэтому я сначала на gitorious наткнулся :). Кстати они еще и сырец своего вебгуя скачать дают, если вдруг это надо.
>> «миллион мух не может ошибаться»©
>> если бы не github, это поделие в жизни бы не вылезло за пределы LKML.
> Наверное именно поэтому я сначала на gitorious наткнулся :). Кстати они еще
> и сырец своего вебгуя скачать дают, если вдруг это надо.Ребят, вы чего? За Git'ом стояло имя Линуса. Этого было более чем достаточно для его популярности, по крайней мере на первых порах. А поскольку он оказался местами весьма толковым, то и успех не заставил себя ждать. А вот если бы его презентовал дядя Петя из Магадана, то шансов пробиться у него было бы меньше.
Я лично всё же почему-то больше люблю Mercurial. :) Но Git'ом тоже иногда пользуюсь, и могу сказать, что для типовых задач они вполне взаимозаменяемы. Можно с тем же успехом спорить Mercedes vs. BMW...
> Быстродействие:
> Высокая производительность работы с хранилищем, не зависящая от числа
> элементом в нем (O(1) revlog);Cool story, bro! Но гит почему-то гораздо приятнее в использовании в этом плане.
hg примерно в двести раз интуитивно понятнее, чем git, и примерно в четыреста раз гибче в настройке как серверной так и клиентской части.и, да, у git в рф кроме "Дровосеков Игнат" из пользователей есть кто-то? ))
> hg примерно в двести раз интуитивно понятнее, чем git, и примерно в
> четыреста раз гибче в настройке как серверной так и клиентской части.ФАКТ! подпишусь под каждым словом
> hg примерно в двести раз интуитивно понятнее, чем git,Я вообще полный чайник во всех DVCS, но нужно было как-то освоить - вдруг пригодится! Начал с git, общую концепцию понял, но всё остальное показалось каким-то мракобесием. Потом решил посмотреть на Mercurial - на удивление, стало понятно сразу всё! С ним и остался.
Мои поздравления разработчикам Mercurial!Поскольку тут идет очередной холивар Mercurial vs Git, хочу поделиться своим опытом. Я люблю и пользуюсь преимущественно Mercurial, но поработав несного с Git должен признать, что в нем тоже есть сильные стороны.
- Чего по-настоящему не хватает в Mercurial - это поддержка нормальных локальных веток. "Bookmarks" - это, конечно, локальные ветки, но недоделанные - с глобальным пространством имен и не всегда работают как надо (не перемещаются вместе с Pull-ом или Merge-а, а только с Commit-ом).
- Очень не хватает "Squash Merge" - объединения, при котором альтернативная ветка объединяется с текущей, в результате чего образуется только один новый коммит. А потом альтернативную ветку можно вообще удалить из интеграционного репозитория. Таким образом главную историю изменений можно держать в чистоте, без коммитов типа "Ой, я забыл добавить файл в проект". Но разработчики Mercurial, похоже, никогда не сделают Squash Merge, поскольку это противоречит идеологии "история священна".
- В Git система хранения репозитория действительно лучше, чем в Mercurial. Меркуриал хранит историю изменений в разрезе файлов и если в процессе истории было много переименований (особенно каталогов), то, во-первых, репозиторий будет занимать значительно больше, а, во-вторых, число файлов в репозитории тоже будет расти и расти. Это сильно нагружает файловую систему. Пример такого репозитория - SLURM. В Git - это 90 МВ и десятки файлов, в Hg - 500 MB и тысячи файлов.Но при всем при этом у Mercurial есть свои плюсы, от которых я не смогу отказаться:
- Поддержка Windows на том же уровне, что и другие ОС,
- Хороший GUI. Это действительно удобно. В Git даже SmartGIT не дотягивает по функциональности до TortoiseHG (нет, blame и datamine, например)
- Локальная нумерация коммитов - тоже очень удобно.
- Встроенный HTTP-сервер. Невероятно удобно.
- Patch Queues - очень функциональная штука. Позволяет использовать ее аналогично Staging Area в git, но плюс еще сотня полезной функциональности.
- Кросплатформенная расширяемость. Это просто "killer feature". Вы пишете (или используете) extension и он один и тот же на всех ОС.
большое спасибо за интересный дельный комментарий, из которого можно узнать интересные факты:
- поддержка нормальных локальных веток
- Squash Merge
- система хранения репозиторияпро локальные ветки не задумывался никогда, squash merge полезная штука, система хранения это да, несколько не оптимальна для вышеописанного случая
кажется знаю что такое локальные ветки, это те что не будут отправляться на сервер с push, важная вещь, и squash merge тоже крайне полезен был бы, уверен что по мере развития в Mercurial в нем появятся и такие возможности
а так да: поддержка любых ОС, удобнейший GUI на PyQt, числовая нумерация коммитов - с ними удобно работать, встроенный сервер! легкую расширяемость достигли используя Python, думаю это плюс выбранной платформы
от себя добавлю, в Mercurial:
- грамотная поддержка "экстерналов" (subrepository) причем штатно как git svn так и самих hg
- контроль доступа к веткам и каталогам файламMercurial лучше подходит для командной разработки в рамках как небольшой так и большой команды, чем git
но с git тоже работал не мало
Хех. По поводу mercutial для большой команды. [Проработанные и опенсорсные] cистемы code review появились?
> Хех. По поводу mercutial для большой команды. [Проработанные и опенсорсные] cистемы code
> review появились?Для Review Board плагин имеется. Хотя вообще мне самому было бы интересно посмотреть на толковое решение для DVCS - пока что всё виденное (не скажу, что сильно интересовался вопросом) было на post-commit'ах.
Ну, в меру толковое решение для git называется Gerrit. У него есть, конечно, свои затыки, но в сравнении с Review Board это просто другой уровень.
Точнее так:когда я последний раз смотрел на Review Board, он весь строился вокруг концепции патча.
Соответственно, работа с цепочкой изменений, отправленных на ревью, становилась, м-м-м, мягко говоря, неочевидной. Ну, разумеется, предполагается, что в ходе ревью какие-то из присланных ченджсетов в цепочке будут изменены, какие-то вообще могут быть выброшены, ну и так далее.
> Точнее так:
> когда я последний раз смотрел на Review Board, он весь строился вокруг
> концепции патча.
> Соответственно, работа с цепочкой изменений, отправленных на ревью, становилась, м-м-м,
> мягко говоря, неочевидной. Ну, разумеется, предполагается, что в ходе ревью какие-то
> из присланных ченджсетов в цепочке будут изменены, какие-то вообще могут быть
> выброшены, ну и так далее.Это зависит от организации процесса... При жёстком требовании использования небольших атомарных коммитов это не проблема. Такое требование имеет свои плюсы в случае обнаружения регрессий уже после коммита - shit happens. Но в более мягкой ситуации, при разработке типичного десктопного приложения - да, будет неудобно.
> При жёстком требовании использования небольших атомарных коммитов это не проблема.фиче-бранчи на двух-трёх человек становятся чудом.
>> При жёстком требовании использования небольших атомарных коммитов это не проблема.
> фиче-бранчи на двух-трёх человек становятся чудом._Иногда_ стабильность важнее скорости вливания фич. :)
> _Иногда_ стабильность важнее скорости вливания фич. :)В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро, и не разваливая основное дерево.
>> _Иногда_ стабильность важнее скорости вливания фич. :)
> В фиче-бранчах-то? Почти никогда. Основная задача фиче-бранча - быть наколбашенным быстро,
> и не разваливая основное дерево.Нет, я имел в виду конечную разрабатываемую систему. Где новые фичи разрабатываются не очень часто, а вот сам процесс ревью довольно жёсткий. Одно дело - видеоплеер у хомячка грохнется, и другое - сбой на конвеере завода или на web-сервисе с посещаемостью на уровне "Яндекса" или "Википедии". Повторюсь, специфика везде своя. :)
> фиче-бранчи на двух-трёх человек становятся чудом.... в том смысле, что фиче-бранч предполагает, во-первых, что изменения колбасятся быстро, без ожидания аппрува каждого коммита прежде чем приступить к следующему, а, во-вторых, работу над одним и тем же кодом ведут несколько человек. Соответственно, у них гарантированно будут пересечения по коду и они будут вынуждены корректировать свои коммиты при изменении коммитов где-то в глубине цепочки/дерева.
> Ну, в меру толковое решение для git называется Gerrit. У него есть,
> конечно, свои затыки, но в сравнении с Review Board это просто
> другой уровень.Да, это уже смотрится интереснее, спасибо за информацию.