Представлен (http://mercurial.selenic.com/wiki/) релиз распределённой системы управления версиями Mercurial 2.8 (http://mercurial.selenic.com). Код Mercurial написан на языке Python (требующие высокой производительности части оформлены в виде модулей на Си) и распространяется под лицензией GPLv2+. Среди проектов, использующих (http://mercurial.selenic.com/wiki/ProjectsUsingMercurial) Mercurial, можно выделить OpenSolaris, NetBeans, OpenJDK, ALSA, Mozilla, Nginx, Xine, Dovecot, NTFS-3G, Python, Vim и W3C.Из изменений (http://mercurial.selenic.com/wiki/WhatsNew) можно отметить реализацию в web-интерфейсе поддержки использования синтаксиса revset при поиске;
добавление файла конфигурации для использования TLS или SSLv23; новое дополнение shelve для сохранения/восстановления save/restore рабочих изменений.
Достоинства Mercurial:- Быстродействие:
- Высокая производительность работы с хранилищем, независящая от числа элементом в нём (O(1) revlog);- Компактное хранение данных в проиндексированном и сжатом виде;
- Оптимизирован для эффективной работы с данными на жёстком диске;
- Все изменения и файлы в репозитории дополнительно проиндексированы;
- Для копирования данных по сети используется HTTP и SSH, данные передаются в сжатом виде.
- Масштабирование
- Распределённая модель разработки позволяет участвовать в проекте неограниченному числу разработчиков;- Допускается произвольное слияние отдельных децентрализованных репозиториев, поддерживаемых отдельными разработчиками;
- Объём репозитория, число файлов и зафиксированных изменений не отражается отрицательно на производительности;
- При работе нет необходимости ждать освобождения блокировки.
- Надёжность.
- Для контроля целостности данных в репозитории используется SHA1;
- Хранилище реализовано в журнальном виде - данные не замещаются, а добавляются. Ведётся журнал транзакций;
- Быстрый алгоритм проверки целостности репозитория;
- Встроенные средства резервного копирования и проверки целостности;
- Удобство использования.
- Привычный CVS-подобный набор команд;
- Наличие встроенной системы подсказки;
- Интегрированный Web-интерфейс;
- Большой выбор GUI интерфейсов (http://www.selenic.com/mercurial/wiki/index.cgi/GUIClients).
- Лёгкость внедрения:
- Поддержка платформ UNIX, MacOS X и Windows;- Средства (http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryCo...), упрощающие миграцию с других систем управления исходными текстами;
- Поддержка нескольких моделей организации репозитория: централизованная cvs-подобная, децентрализованная иерархическая и распределённая полуиерархическая;
- Поддержка внешних обработчиков и дополнений.
URL: http://mercurial.selenic.com/wiki/
Новость: http://www.opennet.me/opennews/art.shtml?num=38336
Обожаю Mercurial и TortoiseHg, но... они пофиксили переименование файла?
Ребят, кто использовал и чем оно субъективно лучше гита?
(надеюсь ты не тролль) По моим ощущениям, простая и логичная система команд, всё просто работает, идеальный GUI для всех ОС.Когда надо что-то в гите сделать - ты роешь кучу мануалов, и оно с десятого раза заработает как надо. А меркуриал - идеология в том что "всё должно работать так как ожидает того пользователь" - в общем, так и есть.
> Когда надо что-то в гите сделать - ты роешь кучу мануалов,Я не рою. Он просто ведет себя так как должна себя вести DVCS. А не позорная мимикрия под "я тут типа SVN с парой добавочных плюшек". Просто используя гит надо осознать как выглядит модель распределенной разработки. И тогда все будет весьма просто и логично.
> Я не рою. Он просто ведет себя так как должна себя вести DVCS. А не позорная мимикрия под "я тут типа SVN с парой добавочных плюшек". Просто используя гит надо осознать как выглядит модель распределенной разработки. И тогда все будет весьма просто и логично.И я не рою - просто Mercurial работает. Как МНЕ надо и так, как я этого ожидаю.
Чем опасен rebase, или как получилось, что 2*3=5: http://habrahabr.ru/post/179123/
Ещё раз о «Mercurial против Git» (с картинками): http://habrahabr.ru/post/123700/
Полезности Mercurial: http://habrahabr.ru/post/188418/
> Чем опасен rebase, или как получилось, что 2*3=5: http://habrahabr.ru/post/179123/Это в тему гита что ли? А причём тут он-то? Типа на меркуриале ребейз не сделаешь шо ле?
> Ещё раз о «Mercurial против Git» (с картинками): http://habrahabr.ru/post/123700/
> Полезности Mercurial: http://habrahabr.ru/post/188418/Ну да, только перманентные ветки - это одновременно главный недостаток. Потому что а) всё это гуано к себе приходится тянуть и оно всё время маячит перед глазами, а в гите всякие стародревние тестовые ветки можно чик-чик pи готово; и б) невозможно тянуть из нескольких репозиториев с переименованием веток. Вот hg'шники и изгаляются в итоге - то переименование веток изобретают, то evolve, то bookmark'и...
> а) всё это гуано к себе приходится тянуть и оно всё время маячит перед глазамизачем вы коммитаете "гуано" в репозиторий?
Если задаете такие вопросы, значит либо не используйте полноценно dvcs, либо делаете очень незначительные правки.
а не могли бы вы раскрыть своё утверждение?
очевидно нет, он занят написанием "гуано" для очередного коммита :)
>> а) всё это гуано к себе приходится тянуть и оно всё время маячит перед глазами
> зачем вы коммитаете «гуано» в репозиторий?тебе не понять, иди отлаживай свой падучий приветмир.
> а) всё это гуано к себе приходится тянуть и оно всё время маячит перед глазамиИстория есть история.
А переписыватели истории плохо кончают, как историей же было показано.
> Я не рою.И я. Просто гуглю "git что_мне_надо_сделать" и в первом результате ответ на stackoverflow.
> Просто используя гит надо осознать как выглядит модель распределенной разработки.Модель разработки в Git как SVN в конечном итоге выглядит.
А в Mercurial работают с лесами, как показывает проект OpenJDK: http://www.youtube.com/watch?v=_Z934djQtiQ
>А в Mercurial работают с лесамиgit submodule? нет, не слышали
я, конечно, понимаю, что git — родина слонов и всё такое прочее, но домашнее задание было бы неплохо делать *прежде* чем заявлять чушь, опровергаемую одной ссылкой (http://mercurial.selenic.com/wiki/Subrepository)что особенно забавно, поддерживаются также репозитории Git — http://mercurial.selenic.com/wiki/Subrepository#Git_subrepos...
Сравнивать git и hg можно только по одному критерию: policy прибита гвоздями или нет?Git и Hg - это как X Window и GTK
> Git и Hg - это как X Window и GTKВсмысле первое работает везде, а второе в некоторых случаях выглядит как гуано и ломает совместимость между версиями?
> Ребят, кто использовал и чем оно субъективно лучше гита?Жрет вагон памяти и тормозит на больших иерархиях. Производители процессоров и памяти одобряют.
Тут обычно многое упоминают, работать можно и с тем и с другим (либо с обоими одновременно используя что-то вроде hggit). В базовом виде функционал и концепция работы очень похожи.Однако есть интересное наблюдение. В гите обычно работают только с одной веткой (не считая слияния, перебазирования и т.п.). Напоминает консоль и текущий каталог строкой. Оно обычно достаточно, но исключает работу со всем содержимым хранилища, а не с конкретными линиями истории. Конечно можно получить список веток и т.п., но общего обзора это не дает. Также и при слияниях обычно не видно обе ветви, а только "основную".
Т.е. на уровне концепции ветвления/слияний гит очень похож на SVN, конечно не в техническом плане, а на уровне пользователя. Опять-таки поддерживается адресация ревизий только по хешу и относительная. Безымянные ветки гит соответственно тоже не поддерживает. Таковые, как я понимаю, попадут под сборщик мусора. Возможно поэтому гите так любят линейность истории и перебазирование.В hg во многих интерфейсах (веб, тортойс, glog, сторонние) отображается не просто текущая ветка, а дерево (граф) веток. Соответственно видны все ветвления и слияния. Причем можно получить полный обзор хранилища с его топологией. Аналогия с деревом каталогов, когда одного взгляда достаточно, чтобы все увидеть. Конечно, работа в "отфильтрованном" виде одной ветки также поддерживается. Есть локальные для данного хранилища номера ревизий, что дает возможность для пользователя обращаться к любой ревизии текущего хранилища не запоминая хеш (но можно и через хеш). Есть поддержка безымянных веток, по сути веткам имена (метки) для работы особо не нужны.
Также ревизии при желании можно и не перебазировать, а сделать обычное слияние.
Это не сильно затруднит чтение истории, так как можно видеть ревизии обеих веток одновременно плюс сам факт слияния и то как оно было сделано.Хотя концепция видения истории изменений данных, а не файлов в гит довольно интересна, меня лично больше привлекает возможность строгого контроля, за историей каждого файла в хранилище.
Кажется, часто защищая гит по сравнению с другими системами, люди просто говорят про плюсы DVCS как таковые. Но гит (и его автор) скорее популяризатор распределенных систем, а не изобретатель. И многие плюсы гит являются плюсами и других распределенных систем.
gitk --all
gitg # в тулбаре выбрать Branches: All Branches(Лично я не пользуюсь, но)при работе через IDE разница между hg и git тоже будет минимальна.
>Безымянные ветки гит соответственно тоже не
> поддерживает. Таковые, как я понимаю, попадут под сборщик мусора. Возможно поэтому
> гите так любят линейность истории и перебазирование.Нет, просто мы любим порядок, а также предпочитаем, чтобы конфликты разрешал автор патча, а не человек, делающий мерж.
> В hg во многих интерфейсах (веб, тортойс, glog, сторонние) отображается не просто
> текущая ветка, а дерево (граф) веток.git log --graph
> предпочитаем, чтобы конфликты разрешал автор патча, а не человек, делающий мержне вопрос, hg rebase присутствует в коробке
семьпицот раз уже задавали этот вопрос везде. Ничем.
Оно всё ещё требует немеренной оперативки при работе с большими файлами?
В достоинствах не увидел лёгких бранчей (без копирования файлов), таки нету?
есть аналог - закладки: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
Я вот кстати долго на меркуриале жил, но на обычных ветках. И, собственно, пожив на перманентных ветках - понял, чем они плохи и почему их в гите таки нет. И зачем, собственно, нужны tracking branches.Но когда я это всё понял - просто перешёл на гит, так и не попробовав букмарки. А тем временем интересно - раз в меркуриале есть лёгкие ветки, там ДОЛЖЕН быть и tracking. Или нет? А если нет - как же там работать с апстримом-то? Вот допустим твой локальный букмарк ушёл вперёд на пару коммитов, и апстрим тем временем тоже ушёл вперёд, история разошлась. Но если нет tracking'а, то букмарк-то один, и не трогая ничего, обновлённый апстримный букмарк записать некуда. Получается что, в момент pull обязательно должно произойти слияние? Или там всё-таки тоже есть что-то типа master + remotes/origin/master?
в меркуриале есть три типа бранчей:
1. анонимные
2. именованные
3. закладки
ни один из них не требует копирования патчей
Распределённая система управления версиями не для бинарников, и тем более не для огромных бинарников. Она для исходного кода.
Ура!
мл***! зачем мне описание его достоинств (я их и так знаю, а потому и использую hg), вместо описания новых фич? распишите плз, что нового и вообще.
+1
видимо их нет, и чтобы новость не казалось скучной и короткой... )
Кто скажет, пространства имён для веток (или хотя бы букмарков) уже появились?Например, как мне получить diff между веткой some_experimental_feature в апстриме на bitbucket и веткой some_experimental_feature в репозитории "вон того чудика с googlecode", при этом не трогая ветку some_experimental_feature в своём локальном репозитории?
Укажи явно номера коммитов, ёпт. Не надо усложнять сущности без необходимости.
Я хочу кликнуть мышкой и получить красивые графики. Чо в этом плохова?
> Кто скажет, пространства имён для веток (или хотя бы букмарков) уже появились?
> Например, как мне получить diff между веткой some_experimental_feature в апстриме на bitbucket и веткой some_experimental_feature в репозитории "вон того чудика с googlecode", при этом не трогая ветку some_experimental_feature в своём локальном репозитории?hg pull в худшем случае просто добавит ветке some_experimental_feature +1 голову (head). Сами разберётесь, где ваши коммиты, а где нет?
ну и потом hg incoming https://code.google.com/p/choodeek_forrrkk/ --branch=some_experimental_feature
Не гит конечно, но всё-равно слишком сложно - darcs куда проще и удобнее.
Соска ещё проще, попробуй.