Вышел Mercurial 1.0

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

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

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

извени.

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

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

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

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

mercurial мегарулит

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

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

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

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

мосье из 80-х? вылазте из танка ;) Жизнь то вокруг давно поменялась.

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

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

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

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

Torvalds: CVS is CRAP!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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.

> "...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.

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

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

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

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

>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.

> 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 :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Для просмотра различий между удалённым репозиторием 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упс...

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

Упс...