LINUX.ORG.RU

Вышел mercurial 0.9.2


0

0

Вышла новая версия распределенной системы управления версиями Mercurial. Несмотря на небольшое увеличение номера версии, изменений много. Самые существенные: улучшена работа с переименованными файлами - операции log и annotate используют историю переименования, а операция merge теперь корректно работает с переименованными файлами и каталогами; changelog преобразуется в/из UTF-8 автоматически; новая схема репозитория для работы на case-insesitive ФС (для пользователей Windows); значительно усовершенствован плагин mq.

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

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от navotno_stoechko

>А чо вас SVN не устраивает? ;>

Нет, но мы счастливы с git

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

> А чо вас SVN не устраивает? ;>

Не устраивает. Нам нужна распределенная система. И жизни^Wработы без mq я уже не представляю.

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

Ничего не понятно из новости. Где это можно приминять? Вот в офисе вместо галимого VSS это подойдёт? Для работы с бинарниыми файлами? Или это для программёров?

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

>> changelog преобразуется в/из UTF-8 автоматически;

>Только changelog? А filename?

Имена файлов тоже, насколько я понимаю. Но у нас нет файлов с русскими именами, так что я не проверял.

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

> Ничего не понятно из новости.

Ну извини, я старался как мог.

> Где это можно приминять? Вот в офисе вместо галимого VSS это подойдёт?

Вместо VSS это применять можно, но вот слово "офис" меня смущает. Кроме того, плагинов для интеграции в IDE у Mercurial пока, в общем-то, нет (но плагин для Eclipse разрабатывается).

> Для работы с бинарниыми файлами?

Подойдет, но с ограничениями - если у вас большие файлы (размером больше, чем оперативная память), то теоретически должно тормозить.

> Или это для программёров?

Для них - точно. Но не только для них :)

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

> Ссылка на книгу битая.

Проверял, клянусь. Видно, сервер лежит. На всякий случай, вот она (на данный момент - действительно битая): http://red-bean.com/~bos/hgbook.pdf

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

Да, похо значит дело пока :(

Файлы-то у нас не такие уж и большие... Доки простые и эксели в основном... Может как и гляну что оно такое из себя.

Жаль, что в портах пока старое оно:

$ esearch mercurial
[ Results for search key : mercurial ]
[ Applications found : 1 ]

* dev-util/mercurial
Latest version available: 0.9.1-r2
Latest version installed: [ Not Installed ]
Size of downloaded files: 1,176 kB
Homepage: http://www.selenic.com/mercurial/
Description: scalable distributed SCM
License: GPL-2

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

Ине неприятно это признавать, но, похоже, Mercurial - это не для вас. А вот Subversion с ее WebDAV - очень может быть.

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

>Ничего не понятно из новости. Где это можно приминять?

где неудобно использовать один репозиторий.

>Вот в офисе вместо галимого VSS это подойдёт?

А что такое VSS?

>Для работы с бинарниыми файлами? Или это для программёров?

С бинарями дружит, не портит их, по крайней мере. Но вообще это для программистов. Мержить и показывать различия между винарями она не умеет.

ещё одно применение - mq. в двух словах сложно объяснить, но очень удобная. позволяет легко вести патч к репозиторию. типа "версионный патч"

adarovsky ★★★★
()

Благородные доны могут указать где можно ознакомиться с моделью данного SCM и ее ключевыми возможностями? Хорошо бы это было кратко и внятно, а то у них на сайте эта тема размазана как манная каша по тарелке...

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

>> А что такое VSS?
>Virtual Space Ship. Типа неуловимого Джо.

Не совсем:
Microsoft Visual SourceSafe

Приходится использовать эту гадость в офисе :( Ищу замену.

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

> Благородные доны могут указать где можно ознакомиться с моделью данного SCM и ее ключевыми возможностями? Хорошо бы это было кратко и внятно

Не встречал хороших кратких введений в DSCM. Хотя нет, вру... есть такой документ. Он относится не к Mercurial, а к BitKeeper, но почти всё транслируется 1:1. Это статья Jeff Garzik "Doing BK thing, Penguin-style". Опубликована была в Proceedings of Ottawa Linux Symposium за 2002 год (кажется :)), и ее когда-то была в каталоге Documentation ядра. Правда, такая полезная вещь, как MQ, там не описана (в BitKeeper ее не было), но ты всегда можешь почитать доку по quilt.

Ну и вот ультракороткое введение от меня лично: существует глобальный DAG версий, каждый узел в этом графе - дерево файлов/каталогов. Новые вершины графа создаются операцией commit. Каждый репозиторий хранит часть этого графа, они передаются между репозиториями командами push и pull. Последняя из важных операций - merge, она создает новый узел графа, объединяющий 2 узла (т.е. у него 2 предшественника, в отличие от узла, создаваемого операцией commit - там предшественник только 1). Вершины графа, у которых нет потомков, называются головами (heads).

В файловой системе репозиторий выглядит как каталог, в котором есть подкаталог .hg, в котором хранится часть глобального DAG (или он весь). Кроме того, репозиторий может иметь (а может и не иметь) рабочее дерево - то дерево файлов/каталогов, которое ты можешь менять в процессе работы, и, фиксируя (commit) которое, ты создаешь новые версии (узлы графа). Такая схема работы приводит к тому, что каждый репозиторий - это практически новая ветка (repository is a branch).

Я немного соврал, когда сказал, что merge создает новый узел - формально, его создает commit, следующий за merge, но это вроде как очевидно.

Вот и всё :) Если что непонятно, спрашивай. И почитай Гарзика.

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

> ещё одно применение - mq. в двух словах сложно объяснить, но очень удобная. позволяет легко вести патч к репозиторию. типа "версионный патч"

А можно поподробнее что за верь такой "mq"?

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

> А можно поподробнее что за верь такой "mq"?

Это плагин для разработки/поддержки набора (стека) патчей поверх некой версии дерева исходников. Если ты следишь за linux-kernel, то видел, что там все (или почти все) новые фичи высылаются в виде серии патчей. mq как раз можно использовать для разработки такой серии.

Если копать немного глубже, то mq - это средство редактирования уже зафиксированных в репозитории версий. Это очень полезно при разработке какой-нибудь фичи с нуля - когда зафиксировал что-то, а потом выяснил, что в зафиксированном - ошибка. Если ты использовал mq, то можешь вернуться и отредактировать уже существующую ревизию, в результате в истории не остается "грязи", "ложных стартов" и т.п. Конечно, всё это нужно делать в своем личном репозитории, потому что если запушишь изменение в общий, потом отредактируешь его в своем, потом запушишь снова - в общем репозитории будут _обе_ версии.

quilt знаешь? Вот это то же самое, но интегрировано с VCS (не надо делать quilt add - я его вечно забывал).

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

> Не совсем: > Microsoft Visual SourceSafe

Суть не меняется - нужно быть полным "джо", чтобы добровольно юзать это дерьмище.

> Приходится использовать эту гадость в офисе :( Ищу замену.

CVS/SVN

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

Это дермище использовалось задолго до меня... Я всего лишь админ и как работает VSS мне глубоко по барабану. Есть более важные задачи. Вот бы как-нить согнать народ на что-то более менее приличное! но с svn и cvs я не сталкивался реально. И что ставить нужно я тож не представляю :(

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

> Ну и вот ультракороткое введение от меня лично...

Граф версий соотносится с файлом или или с множеством файлов?

(это вопрос про changesets, возможность переименования/копирования файла и сохранение истории при таких операциях)

Properties? (т.е. links, аттрибутика/возможность работы с нетекстовыми файлами).

Импорт/экспорт в другие SCM?

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

> Граф версий соотносится с файлом или или с множеством файлов?

Каждый узел графа - дерево файлов/каталогов, так что записывается именно версия всего дерева, и граф версий - это граф версий дерева. Хранится, естественно, по-другому, но это деталь реализации :)

> Properties?

SVN user? ;)

> (т.е. links,

symlinks - не поддерживаются пока (есть неопределенные планы, но над этим никто не работает сейчас)

> аттрибутика

Не совсем понял. Если это properties а-ля SVN, то такого нет. Вообще, подход несколько другой - даже теги хранятся в обычном файле.

> возможность работы с нетекстовыми файлами).

Все файлы считаются нетекстовыми.

> Импорт/экспорт в другие SCM?

Есть импорт из git, остальное - только с помощью tailor. Когда я конвертировал наши SVN-репозитории, пришлось ограничиться только trunk'ами.

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

> Все файлы считаются нетекстовыми.

Хранятся increments или полностью?

Если трактовать все как нетекстовое, то это ведет к проблемам с diff/merge.

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

>> Все файлы считаются нетекстовыми.

> Хранятся increments или полностью?

зачем тебе такие детали? :D Естественно, хранятся только дельты, но иногда - и полные файлы тоже. Деталей о том, как это определяется, я уже не помню, но формат хранения эффективный, называется revlog(-NG).

> Если трактовать все как нетекстовое, то это ведет к проблемам с diff/merge.

Проблемы будут только с тем, что _действительно_ нетекстовое (а с этим проблемы будут у любой системы). К тому же формально в Mercurial merging не является частью системы - когда надо merge 2 файла, вызывается внешняя программа (в стандартной поставке такая есть - враппер для нескольких визуальных merge-программ).

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

> Есть импорт из git, остальное - только с помощью tailor. Когда я конвертировал наши SVN-репозитории, пришлось ограничиться только trunk'ами.

tailor, когда я его последний раз смотрел, был довольно крив (пытался им сконвертить репозиторий из svn - помню были какие-то проблемы).

Вообще, лично мне больше git понравился, в первую очередь своей идеей - идентификация любого объекта (файла, дерева файлов, коммита) по его хэшу.

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

> > Хранятся increments или полностью? > зачем тебе такие детали? :D

Это косвенная информация о размерах репозитория и скорости его роста.

> Проблемы будут только с тем, что _действительно_ нетекстовое ... > К тому же формально в Mercurial merging не является частью системы - когда надо merge 2 файла, вызывается внешняя программа (в стандартной поставке такая есть - враппер для нескольких визуальных merge-программ).

Тогда, похоже, merge не является её сильной стороной...

Спасибо за консультацию.

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

> Сегодня нет никаких причин переходить на CVS

Ну почему же нет - припрутся какие-нибудь аутсорсеры и скажут мол, "дык эта, у нас все в CVS, пещерныяяяя людя мы, пощади, не лишай живота!" - проще будет их отреплицировать, нежели применять какие-то другие схемы. Особенно если тайна и все дела.

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

> Это дермище использовалось задолго до меня... Я всего лишь админ и как работает VSS мне глубоко по барабану. Есть более важные задачи. Вот бы как-нить согнать народ на что-то более менее приличное! но с svn и cvs я не сталкивался реально. И что ставить нужно я тож не представляю :(

Ставь SVN, там онлайновая навигация по репозиторию из коробки и бинари нормально цепляются. Единственный косяк - нагрузка на винты клиента больше, ежели делать выгрузки по *-дцать гигов - то напрягает.

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

>> Сегодня нет никаких причин переходить на CVS

>Ну почему же нет - припрутся какие-нибудь аутсорсеры

Это да, но речь шла о _переходе_ на CVS.

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

> Тогда, похоже, merge не является её сильной стороной...

Почему ты так решил? Там вполне достойный merge, на уровне всех современных систем (monotone, bazaar-ng). Точно лучше, чем в SVN. Как я думаю, лучше, чем в git (потому что учитывает переименования).

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

> tailor, когда я его последний раз смотрел, был довольно крив

Мне на одноразовую конвертацию вполне подошел.

> Вообще, лично мне больше git понравился

А я git ниасилил - такое впечатление, что он написан инопланетными роботами для инопланетных роботов.

> в первую очередь своей идеей - идентификация любого объекта (файла, дерева файлов, коммита) по его хэшу.

А я никогда не понимал, зачем нужно идентифицировать столько объектов. И уж точно - мне как пользователю всё это не нужно, достаточно идентификатора зафиксированного дерева файлов (в Mercurial это тоже хэш, как ты знаешь :))

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

> Это да, но речь шла о _переходе_ на CVS.

Ну например с 6-й VSS-ки - очень даже оправдано, особенно если CVS поднята на юниксах. Я ж ее как в первый увидал - так неокрепшей децкой психике чуть кирдык не наступил.

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

>> Это да, но речь шла о _переходе_ на CVS.

>Ну например с 6-й VSS-ки - очень даже оправдано,

Не-а. Сразу на SVN. Нет _никакого_ смысла переходить на давно устаревшую CVS. То, что она лучше VSS - не довод.

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

Забей. Раз мержиться не надо, то VSS сойдет.

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

> Вообще, лично мне больше git понравился, в первую очередь своей идеей -идентификация любого объекта (файла, дерева файлов, коммита) по его хэшу.

Эту мега-идею сейчас все подряд используют, меркуриал тоже.

На мой вкус главная сека в очень простом (ненавязчивом) использовании, настройке, компактности репозитория и очень высокой производительности. Очень легко хачить если чего нехватает. Отлично работает под оффтопик (с небольшой доработкой напильником за пару часов).

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

> На мой вкус главная сека в очень простом (ненавязчивом) использовании, настройке, компактности репозитория и очень высокой производительности.

Аминь, брат! :D

А сейчас еще и переименование более/менее нормально заработало (точнее, будет в 0.9.3) - будет нам вообще счастье 8)

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

>Это косвенная информация о размерах репозитория и скорости его роста. С этим практически лучше всех. revlogNG реально рулит. Причем все автоматически, никаких ручных операций как в git.

>>К тому же формально в Mercurial merging не является частью системы - когда надо merge 2 файла, вызывается внешняя программа (в стандартной поставке такая есть - враппер для нескольких визуальных merge-программ). >Тогда, похоже, merge не является её сильной стороной...

Не совсем так. Речь идет о вызове стороннего визуального 3-way merge. Было бы глупо свой писать. Cherry picking присутствует в виде плагина transplant, вполне себе миленько. Правда пока не применившийся патч надо руками ресолвить, гуй не зовется.

Так что не хуже других. По мержам говорят базарНГ чемпион вроде.

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

> Отлично работает под оффтопик (с небольшой доработкой напильником за пару часов).

Где грабли? Я хочу посоветовать Mercurial виндовой команде.

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

>changelog преобразуется в/из UTF-8 автоматически

то есть если я в виндах скажу hg commit -m "супер пупер изменения" то оно автоматом перекодирует из cp1251 в utf-8?

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

> Файлы-то у нас не такие уж и большие... Доки простые и эксели в основном... Может как и гляну что оно такое из себя.

наверно в этом случае лучше использовать svn

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

> то есть если я в виндах скажу hg commit -m "супер пупер изменения" то оно автоматом перекодирует из cp1251 в utf-8?

При правильно настроенной локали (или как это в винде называется) - да. Но вопрос в другом - а что делать с репозиториями, в которых уже есть log-мессаги в cp1251 :)

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

С mercurial в виндах я пока заметил одну проблему -- кодировка истории (если не извращаться с вызовом внешнего редактора и руками не сохранять в utf-8) и кодировка имен файлов. Если в 0.9.2 это пофикшено то уже можно юзать.

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

1. crlf-ные приколы, если не удалять/вставлять плагином как рекомендуется: * в patch передавать --diff * вроде еще было, надо подифиться 2. extdiff закавычивает имя проги, и винда ее не запускает 3. hgk требует фиксов. заодно приделал вызов vdiff к указанным ченжсетам 4. репозитории в корень диска не класть

Больше не помню на вскидку. Мелочь в целом. Могу патчами поделиться если будет желание. С кириллицей пока не тренировался.

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

* в patch передавать --diff

Пардон, --binary

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

> Не-а. Сразу на SVN. Нет _никакого_ смысла переходить на давно устаревшую CVS. То, что она лучше VSS - не довод.

Просто если напрямую сравнивать всс-ку с SVN - то шок от разницы быдет слишком силен :) А что лучше сразу - дык это понятно...

e
()

Поставил. Похоже пипец всем русским логам наступил (хранилось в utf-8). По крайней мере при просмотре через web интерфейс одни вопросы. Через trac-mercurial те же яйца вид сбоку.

Reset ★★★★★
()

С русскими файлами как была жопа так и осталась. Создаю в виндах русский файл, коммичу, делаю push на linux там файл НЕ перекодируется в кодировку локали.

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

> Поставил. Похоже пипец всем русским логам наступил (хранилось в utf-8)

На Линуксе - всё путем. Попробуй явно задать --encoding

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