LINUX.ORG.RU

Вышел Mercurial 1.0

 ,


0

0

Вышла версия 1.0 распределенной системы управления версиями Mercurial.
Эта версия содержит много изменений по сравнению с предыдущей (0.9.5):

  • улучшения в поддержке копирования/переименования файлов,
  • улучшенная конфигурация программ слияния файлов (возможно задание разных программ для разных типов файлов),
  • поддержку преобразования из Monotone и GNU Arch,
  • множество мелких доводок,
  • и, главное, новый логотип :)
Из новых "официальных" плагинов нужно отметить inotify (Linux-only плагин, намного ускоряющий поиск измененных файлов в большом дереве, и дающий почти мгновенный status и diff) и record (интерактивный commit).

Сайт проекта

Руководство пользователя (неофициальное, aka Mercurial Book).

>>> Подробности

как я ненавижу этот зоопарк.

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

средний дистриб линукса - зоопарк.

zort
()

извени.

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

> что бы поставить полный набор современных VCSов нужна целая куча интерпретаторов, сторонних либ.

А зачем вам полный набор?

> средний дистриб линукса - зоопарк.

От хозяина зависит. Помойку ожно где угодно устроить. Но чистку нужно начинать с собственной головы.

andreyu ★★★★★
()

mercurial мегарулит

anonymous
()

Надо будет попробывать его освоить. По отзывам, он превосходит CVS, Subversion и подобные системы.

---
С Уважением,

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

мосье смотрит на неджитованные языки без ненависти ? залазьте обратно в танк чтоб никому не мешать жить.

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

> и чем вам не угодил CVS ? ;)

Рекомендую посмотреть "Tech Talk: Linus Torvalds on git" на YouTube. Вообщем-то довольно аргументировано выступает :)

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

> Linus Torvalds on git" на YouTube. Вообщем-то довольно аргументировано выступает :)

Torvalds: CVS is CRAP!!!

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

>Вообщем-то довольно аргументировано выступает :)

быгыг. "People that use CVS are stupid and ugly."

хотя я с ним согласен.

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

>Теперь надо его поддержку для эклипса нормальную и можно жить.

+1. Существующий плагин -- хлам какой-то :/

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

>Но чистку нужно начинать с собственной головы.

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

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

> и чем вам не угодил CVS ? ;)

Есть такая программерская болезнь - изобретать велосипеды. Каждый считает, что сделает колесо круглее, а педали педальнее. Естественно, в ход идут ЛЮБЫЕ библиотеки, которые автору захотелось применить, прочитав очередной обзор на ЛОРе или другом линуксайте. Мрак....

Опять же, как прогер скажу, что задачи "контроля версий" могут быть ОЧЕНЬ различные - от простого сохранения дневной работы, до распределённой сборки и компилляции сложного проекта. Есессно, НУЖНО иметь несколько VCS'ок, заточенных под свой круг задач, но разве это кто-то понимает? Каждый считает себя творцом нетленного контроллера мегаверсий, выпуская недовелосипед-недолодку, полную идиотичных багов и экзотических утилит. Ну... туда им и дорога.

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

> согласен. прежде всего выкинуть пристрастие к поделиям, написаным на всякой фиготени и асилить, наконец, git.

А чем неугодили mercurial/bzr/darcs/whatever?

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

> ещё неплохо бы что-то вроде kdesvn. ибо полезно порой бывает

Есть TortoiseHg (http://tortoisehg.sourceforge.net/), она умеет делать GUI к командам hg на Линуксе (hgtk). Ну и вообще вот: http://www.selenic.com/mercurial/wiki/index.cgi/OtherTools

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

> прежде всего выкинуть пристрастие к поделиям, написаным на всякой фиготени

Чо, на Lua уже написали DVCS? :D

> и асилить, наконец, git.

Зачем? "Нас и здесь неплохо кормят" (c)

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

> Есть такая программерская болезнь - изобретать велосипеды. Каждый считает, что сделает колесо круглее, а педали педальнее. Естественно, в ход идут ЛЮБЫЕ библиотеки, которые автору захотелось применить

Ты не в теме. Сливай свой мутный поток сознания в канализацию, а не на ЛОР.

> как прогер скажу, что задачи "контроля версий" могут быть ОЧЕНЬ различные - от простого сохранения дневной работы, до распределённой сборки и компилляции сложного проекта.

"Распределённая сборка и компилляция сложного проекта" у тебя задача VCS? Ты просто гигант мысли.

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

> http://novemberain.com/2008/3/25/on-git-hg-darcs-and-fud

"...and thus much much much harder to understand" -- обалдеть аргумент в пользу git :)

Оттуда же с комментов:

Just a small note: when I was considering Darcs vs Git, sure, the fact that Git is used for Linux kernel development came up. But I one thought came into my mind: if it suits for Linux kernel dev doesn't mean it will suit for your needs.

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

> "...and thus much much much harder to understand" -- обалдеть аргумент в пользу git :)

Важно не то, что написано, а то как процитировать? Давал бы полную фразу, которая звучит:

Git will always be much much much more advanced and thus much much much harder to understand.

Хороший аргумент в пользу git-a.

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

>А чем неугодили mercurial/bzr/darcs/whatever?

тем, что для них надо ещё какие-то левые интерпретаторы непонятно чего тащить.

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

>Чо, на Lua уже написали DVCS? :D

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

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

>Git will always be much much much more advanced and thus much much much harder to understand.

ну, это от склада ума, видимо, зависит. например, для меня svn — это much much much harder to understand, нежели git.

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

> Git will always be much much much more advanced and thus much much much harder to understand.

>Хороший аргумент в пользу git-a.

Обе части фразы ложны. Git не "much much much more advanced", а всего лишь "more advanced", и не "much much much harder to understand", а всего лишь "much harder to use" (потому что все современные DVCS понять одинаково трудно/легко - они как близнецы). Стоят ли "more advanced" фишки использования - каждый решает для себя. Но если кому-то нужна навороченная VCS, которую написал сам Линус и которой пользуются при разработке ядра - Git ждет вас с полным набором граблей :D

Я бы сравнил Git с Гентой или Слакой, а Mercurial - с Debian stable :)

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

>> А чем неугодили mercurial/bzr/darcs/whatever?

> тем, что для них надо ещё какие-то левые интерпретаторы непонятно чего тащить.

У тебя в системе нет Питона? :D Ну а DARCS - это автономный бинарь, ему вообще ничего не нужно.

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

>что бы поставить полный набор современных VCSов

ахиунг! манерные техно-коллекционеры детектед!

>средний дистриб линукса - зоопарк.

это ты еще вантуза или фряхи не видел

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

> Я бы сравнил Git с Гентой или Слакой, а Mercurial - с Debian stable :)

Не ври, Дебиан не настолько тормознее Генты :)

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

>> Я бы сравнил Git с Гентой или Слакой, а Mercurial - с Debian stable :)

> Не ври, Дебиан не настолько тормознее Генты :)

У меня Mercurial не тормозит. ЧЯДНТ?

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

>Я бы сравнил Git с Гентой или Слакой, а Mercurial — с Debian stable :)

что-то в этом есть. для хомячков — Mercurial, для серьёзной работы — git. %-)

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

>У тебя в системе нет Питона?

нет. а нафиг он мне нужен?

>DARCS - это автономный бинарь, ему вообще ничего не нужно.

кажется, когда я смотрел, оно хотело хаскель. или написано на хаскеле? или я попутал?

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

> для хомячков — Mercurial, для серьёзной работы — git. %-)

Ну дык йопт, а настоящие мужчины используют Фортран на голом железе.

> оно хотело хаскель. или написано на хаскеле?

Оно написано на Хаскеле, компилируется в нативный бинарь.

> или я попутал?

Попутал. Причем не только это.

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

У меня практически нет опыта работы с mercurial. Для просмотра различий между удалённым репозиторием git и локальным достаточно сделать git-fetch и, например, git-show-branch master remotes/master. Потаскать через git-cherry-pick нужные коммиты и веселиться дальше. Причем всё творится локально (кроме git-fetch). Есть ли аналогичные подходы в mercurial?

И чем Вам лично (только объективно) не нравится git (кроме неюзабельности под виндой)? Может чего-то не хватает? Очень интересно послушать.

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

>Попутал. Причем не только это.

не попутал. таки хаскель. то, что нельзя пересобрать при наличии исходников, нефиг и ставить. git я скачал, пнул — собралось. а тут ещё неведомый компилятор тащить…

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

> Чо, на Lua уже написали DVCS? :D

Есть monotone, где lua используется в качестве встроенного языка.

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

>"Распределённая сборка и компилляция сложного проекта" у тебя задача VCS? Ты просто гигант мысли.

вообще-то да. Подзадача процесса конфигурационного управления, "хранить неполоманные билды", учитывая что версия из SVN может и не собраться :) но tagged оттестированная сборка -- наверняка соберётся :) то есть, хранение в VCS параметров сборки, отчетов от buildbot, логов сборки чтобы докопаться "почему автоматическая сборка из SVN не компилируется" итп.

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

>> "Распределённая сборка и компилляция сложного проекта" у тебя задача VCS? Ты просто гигант мысли.

> вообще-то да.

Вообще-то нет.

> "хранить неполоманные билды", учитывая что версия из SVN может и не собраться :) но tagged оттестированная сборка -- наверняка соберётся :) то есть, хранение в VCS параметров сборки, отчетов от buildbot, логов сборки чтобы докопаться "почему автоматическая сборка из SVN не компилируется"

Вообще-то "задача хранения" результатов сборки - это не "распределённая сборка и компилляция сложного проекта". В противном случае в VCS встраивался бы buildbot и distcc.

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

> Для просмотра различий между удалённым репозиторием git и локальным достаточно сделать git-fetch и, например, git-show-branch master remotes/master.

Я не настолько хорошо знаю git, чтобы перевести это в hg :) Просмотр изменений, которые есть в удаленном, но нет в локальном - hg in. При желании можно сделать hg pull и посмотреть разницу hg diff. Но вообще-то рекомендуемая практика - держать "чистый" клон upstream.

> Потаскать через git-cherry-pick нужные коммиты и веселиться дальше.

Если бы ты еще определил, что значит "веселиться"... планируется ли слив изменений в upstream, и если да - то в каком виде? Патчи? git push? Cherrypicking (очень плохо определенный термин, кстати) есть и в Mercurial (плагин transplant), но я им не пользуюсь.

> Причем всё творится локально (кроме git-fetch). Есть ли аналогичные подходы в mercurial?

Да. Еще раз повторю - они есть _везде_, в любой современной DVCS. У половины из них (Mercurial, Git) даже корни общие - от Monotone и OpenCM. Разница - только в том, на какой workflow они настроены - Git настроен на (модный 8)) workflow ядра Линукс, Mercurial - ни на какой особенный. Архитектура же hg, git и mtn схожа до идентичности - распределенный граф версий, построенный на криптографических хэшах.

> И чем Вам лично (только объективно) не нравится git

Любое "не нравится" субъективно :) Когда я выбирал DVCS, в Git не понравилось то, что его CLI был безнадежно (и ненужно) наворочен - такое впечатление, что его делали инопланетяне для инопланетян (или тех, кто хочет ими стать). Я понимаю, что Git начинал свою жизнь как "git plumbing", и читал, что с тех пор CLI сильно улучшили/упростили (приблизив к hg, svn и cogito :)), но всё же... зачем _мне_ всё это? По моим наблюдениям, git любят те, кому нравятся мощные навороченные системы, даже если они используют их возможности процентов на 20% - но зато есть "чувство причастности" :)

В общем - для меня Git оказался неудобен в использовании и перегружен ненужными фишками. Поскольку Mercurial тогда уже "вставал на крыло", необходимости асиливать Git я не видел. Вот что думали другие: http://www.opensolaris.org/os/community/tools/scm/history/ (можно еще поискать, почему Xen не стал использовать Git).

Кстати, X.org перешел на Git благодаря наглости и прямой лжи Кита Пакарда :)

> (кроме неюзабельности под виндой)?

Как раз это мне безразлично - вендой не пользуюсь. Хотя для других - это серьезный довод в пользу Mercurial.

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

>Вообще-то нет.

Вах, уличил. Ну не гигант мысли, так что уж теперь.

>Вообще-то "задача хранения" результатов сборки - это не "распределённая сборка и компилляция сложного проекта".

вообще-то "распределённая сборка и компилляция сложного проекта" -- это вообще не задача, неинтересный промежуточный этап :) откомпилировать "сложный проект" из SVN распределённо не сложно технически. Сложнее логически, чтобы всегда собиралось :)

>В противном случае в VCS встраивался бы buildbot и distcc.

а что, оно и багтрекинг туда не встраивается? В смысле, интегрируется в общий процесс, а не прям именно в VCS. "Задача хранения" -- тоже проста, интереснее вопрос, как, что и когда (оттестированное) хранить, чтобы всегда собиралось :)

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

> Вообще-то "задача хранения" результатов сборки - это не "распределённая сборка и компилляция сложного проекта". В противном случае в VCS встраивался бы buildbot и distcc.

А что мешает это сделать?

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

Не в тему: даже такая тривиальная утилита как diff, расширенная до синтаксической обработки программных исходников, может сэкономить пересылку несущественных изменений (добавление комментов, пустых строк...). Хотя казалось бы, изначально это всего лишь сравнивалка текстов.

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

>> Вообще-то "задача хранения" результатов сборки - это не "распределённая сборка и компилляция сложного проекта". В противном случае в VCS встраивался бы buildbot и distcc.

> А что мешает это сделать?

Здравый смысл. Но тебе не эта мелочь мешает, конечно.

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

Манилов детектед.

tailgunner ★★★★★
() автор топика

>и, главное, новый логотип :)

лапа гнома detected :)

anonymous
()

Hg рулит. Для ковыряния в одно рыла проекта, развёрнутого в нескольких местах - самый руль.

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

>>> Вообще-то "задача хранения" результатов сборки - это не "распределённая сборка и компилляция сложного проекта". В противном случае в VCS встраивался бы buildbot и distcc.

>> А что мешает это сделать?

>Здравый смысл.

Чушь не городи?

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

>Манилов детектед.

Неандерталец спредэд ту зе битс.

Beyond Compare (ха-ха, на Виндовозе!) поддерживает именно синтаксический анализ. Но олухам с Линукса достижения современности не нужны - изобретут ещё 10 сравнивалок под разные библиотеки!

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

> Beyond Compare (ха-ха, на Виндовозе!) поддерживает именно синтаксический анализ

и делает это именно чтобы "сэкономить пересылку несущественных изменений (добавление комментов, пустых строк...)", да? Какая трата ресурсов. Слушай, а изменения комментариев - они вендузятнегов не волнуют?

Кроче, студент... еды нет.

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

> как я ненавижу этот зоопарк.

> что бы поставить полный набор современных VCSов нужна целая куча интерпретаторов, сторонних либ.

"полный набор современных VCSов" - это и есть зоопарк.

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

> Опять же, как прогер скажу, что задачи "контроля версий" могут быть ОЧЕНЬ различные - от простого сохранения дневной работы, до распределённой сборки и компилляции сложного проекта. Есессно, НУЖНО иметь несколько VCS'ок, заточенных под свой круг задач, но разве это кто-то понимает? Каждый считает себя творцом нетленного контроллера мегаверсий, выпуская недовелосипед-недолодку, полную идиотичных багов и экзотических утилит. Ну... туда им и дорога.

Знаешь, почему ты злишься? Потому что ты ленивый и тупой, потому что ты не в состоянии осилить новые удобные инструменты и технологии. Какие ещё у тебя круги задач, которые требуют разных VCS? Уверен, что mercurial'а хватило бы за глаза для всех твоих задач.

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

>Знаешь, почему ты злишься? Потому что ты ленивый и тупой, потому что ты не в состоянии осилить новые удобные инструменты и технологии. Какие ещё у тебя круги задач, которые требуют разных VCS? Уверен, что mercurial'а хватило бы за глаза для всех твоих задач.

Как на Mercurial сделать такую _простейшую_ вещь - checkout только одного каталога проекта?

Упс...

А как насчёт svn externals?

Упс...

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