LINUX.ORG.RU

Вышел Mercurial 1.9

 , , ,


0

2

Точно по расписанию вышла очередная версия распределенной системы контроля версий Mercurial - 1.9. Самые значительные изменения:

  • новый язык для указания множества файлов filesets
  • Улучшен алгоритм поиска чейнджсетов в удаленных репозиториях (команды findincoming, findcommonincoming, findoutgoing, prepush).
  • Сервер команд для доступа к API через пайп.
  • Экспериментальный формат хранения generaldelta
  • Новый экспериментальный клиент HTTP

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

Перед апгрейдом не забудьте прочитать замечания о совместимости

Скачать

>>> Полный список изменений

★★★★★

Проверено: maxcom ()
Последнее исправление: provaton (всего исправлений: 4)

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

> Он умеет докачку или такое бесполезное поделие для больших проектов как и гит?

Не умеет. :(

Поэтому не нужно закапывать svn. Впрочем, с такой категоричностью, как здесь, только школьники могут орать, а им решать что и где закапывать даже в придомовой песочнице не доверят, поэтому пусть орут.

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

> Но Windows поддерживается официально, значит такой баг можно рассматривать как отсутствие поддержки Unicode...

... в Windows. В Windows вообще много чего не поддерживается, и это далеко не новость.

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

>> Он умеет докачку или такое бесполезное поделие для больших проектов как и гит?

Не умеет. :(

Это делается скриптом из 3-х строк.

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

> Дело в том, что к этому релизу я сделал перевод всех встроенных хелпов ртути.

Respect! А балаболов не слушай, пусть балаболят. Мало ли, что им не нужно. Их послушать, так для них и их собственная голова - совершенно лишний предмет.

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

> Внутри Qt всë UTF-16, внимательней читай доки и/или смотри исходники. Пардон, погорячился, но всё остальное остаётся в силе.

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

ну хотя бы тем, что они навязывают конкретный вид отступа (4 пробела, если я всё помню)

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

Я на плюсах последний раз писал полгода назад :)

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

svn прост как валенок, а на счет ненадежности и тупости соглашусь. но после git'а люди не перестанут бояться версионных систем, скорее наоборот, ибо он неадекватно сложен

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

NT-линейка винды поддерживает юникод с самого своего появления в начале 1990-х. Более того, юникод является для неë «родным» и функции для 8-битных кодировок [в большинстве своëм] являются обëртками к их юникодным эквивалентам. То, что некоторые слоупочные разработчики вот уже 8 лет (с 2001-го года, когда вышла XP и окончательно решили пересадить десктопы с говно-9x на вполне вменяемые NT) не могут отвязаться от привычек времëн Win9x - проблема не винды.

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

это не баг, в венде надо по особому настраивать .hgrc, тогда будет всё ok

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

> он неадекватно сложен

Ну, справедливости ради стоит отметить, что базовые Git-овские команды типа clone, pull, commit, push и некоторых других достаточно просты, если не слишком залезать в дебри их параметров. Для не шибко замороченных проектов при отсутствии необходимости/желания поизвращаться этого достаточно. Да и некоторые свойственные DVCS фичи наподобие отсутствия необходимости коннектиться к серверу почти на каждый чих весьма удобны.

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

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

А можно на эти 3 строки посмотреть? (Не троллю, интересуюсь. Спасибо большое за ссылку на A Guide to Branching in Mercurial)

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

Ну вгет-то докачает в таком случае, а хг - сфейлит. Слили мы, хвостострел, фигня этот наш меркуриал.

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

Хм. Что именно докачает wget?

зип с репом, например. Забей, тупак это все. Надо спать.

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

>svn прост как валенок,

Архитектура svn примитивней. А сам свн куда сложней, чем аналогичный вариант использования git. Git хотя бы сам ловит переименование файлов, а не как этот свн, где все команты cp, mv и тому пдобные повторены в самом клиенте.

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

>Ну, справедливости ради стоит отметить, что базовые Git-овские команды типа clone, pull, commit, push и некоторых других достаточно просты, если не слишком залезать в дебри их параметров. Для не шибко замороченных проектов при отсутствии необходимости/желания поизвращаться этого достаточно. Да и некоторые свойственные DVCS фичи наподобие отсутствия необходимости коннектиться к серверу почти на каждый чих весьма удобны.

именно. Этого вполне достаточно, чтобы перейти на него с svn. Собственно, svn не умеет даже этого.

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

>С Юникодом в консоли Windows проблем не обнаружено. Я же ввел гамму и увидел гамму в выводе dir.
КАК ты это сделал?
и еще вопрос - у тебя виндовая консоль всегда корректно отображает юникод? т.е. если какая-нибудь гну софтина вывалит стену русского текста в utf8 то в консоли будет русский текст, а не «кракозябры»?

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

Да, я тоже не понял, как? Я не смог ввести ничего, кроме крякозябров, в виндовую консоль, сколько ни мучался. Ни набором. ни копированием.

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

> КАК ты это сделал?

Само так получилось. Гамму копипастил из таблицы символов.

и еще вопрос - у тебя виндовая консоль всегда корректно отображает юникод? т.е. если какая-нибудь гну софтина вывалит стену русского текста в utf8 то в консоли будет русский текст, а не «кракозябры»?


Я и сам удивился, когда dir/echo отработали с юникодом без проблем. Пробовал diff(.exe). Корректный выхлоп дает только для файлов в cp1251.

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

>ставит себе в заслугу освоение ненужной фигни и, хуже всего, начинает впаривать ее окружающим.

троллинг в стиле вендузятников, которые так говорят про линукс

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

В UTF-8 нельзя, надо в UTF-16.

Это будет работать, если ты во всех программах заменишь вызовы open(), fopen() и т.д. на их UTF-16 аналоги: в данном примере это _wopen() и _wfopen().

В этом основной butthurt при портировании на венду.

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

команды типа clone, pull, commit, push и некоторых других достаточно просты, если не слишком залезать в дебри их параметров

ты забыл написать, что для получения сорцов тут аж 3 команды — pull, fetch и checkout ... и вот так во всём ...

Да и некоторые свойственные DVCS фичи наподобие отсутствия необходимости коннектиться к серверу почти на каждый чих весьма удобны.

так почему именно git ? hg умеет все тоже самое, но лишен его недостатков

Reset ★★★★★
()

Вопрос к собравшимся hg-юзерам. HG умеет хранить в репе пустые директории. Или он, как и гит, «не предназначен для этого»?

А то есть проект в гите - нужно хранить дерево каталогов для девайса. Чтобы гит хранил пустые директории приходится делать их непустыми - запихивать в каждую файлег .gitplaceholder. Он вроде бы как никому и не мешает, но какое-то корявое решение.

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

hg тоже «не предназначен».

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

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

> HG умеет хранить в репе пустые директории?

Нет. Тоже нужно класть .placeholder

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

> и еще вопрос - у тебя виндовая консоль всегда корректно отображает юникод?

Надо ставить шрифты Lucida Console.

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

>> Способ, которым он их ловит, крив by design.

Интересно почему?

Вот такой случай: нужно разбить файл на 2, и естественно, отредактировать каждый процентов на 50. После этого, если хочешь увидеть правильную историю, придется указывать при git log сходство в 50%. И непонятно, какие зомби вылезут от этого.

Вообще, у git дела со следованием истории файла еще хуже, чем в Mercurial (хотя и в Mercurial не блестяще).

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

> Ну а если так, то правильней и удобней хранить дерево в текстовом виде в файлике, либо еще в каком-нибудь виде, из которого ее можно сгенерить и залить на целевую машину.

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

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

(хотя и в Mercurial не блестяще).

А у кого блестяще? И возможно ли теоретически предусмотреть все юз-кейсы, которых over 9000?

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

> А у кого блестяще?

Думаю, что у Monotone - они специально для этого многое делали. Возможно, и у bzr - у них с Monotone общий подход (идентификаторы файлов).

И возможно ли теоретически предусмотреть все юз-кейсы, которых over 9000?

Множество-то конечное - значит, можно :)

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

>В Qt например хорошо сделано: внутри Qt всё UTF-8, но при вызове вендового API конвертится в UTF-16.

Кажется вы не слушаете. Qt работает в консоли? Нет?

Точно те же проблемы у Far. А вот у графических менеджеров их нет. Спросите Рошаля почему так? Или возьмите распакуйте архив winrar а потом консольной версией (архив с греческими буквами).

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

>То, что некоторые слоупочные разработчики вот уже 8 лет (с 2001-го года, когда вышла XP и окончательно решили пересадить десктопы с говно-9x на вполне вменяемые NT) не могут отвязаться от привычек времëн Win9x - проблема не винды.

Ага, ага. cmd тоже не умеет работать с UTF-8. Почему? Странно да?

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

>Это будет работать, если ты во всех программах заменишь вызовы open(), fopen() и т.д. на их UTF-16 аналоги: в данном примере это _wopen() и _wfopen().

Короче - читаем тут http://www.python.org/dev/peps/pep-0277/

опять же все хорошо в cygwin

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

> в начале 20-х годов двадцать первого века

не путай второе десятилетие и двадцатые годы

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

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

Если же ты используешь в итоговой ФС компоненты, которые разрабатывал не ты (например, всякие загрузчики, утилиты busybox и др., что там у вас) и которые нет смысла генерить из исходников каждый раз, то я бы просто поместил их в специальный каталог, типа binaries, примерно соблюдая конечную иерархию для наглядности. А при сборке создавал бы полную иерархию целевой ФС и копировал нужные файлы туда из binaries/. Так сохранится наглядность, не нужно хранить пустые каталоги, и самое главное, что теперь у тебя скрипт, который создает целевую ФС, под контролем версий, поэтому всегда можно посмотреть, какие каталоги были на такой-то момент времени. При этом если надо переместить бинарники из одной папки в другую, они не будут физически копироваться/перемещаться в репозитории, захламляя историю и место. Мерж при этом тоже существенно облегчается.

Поэтому мне кажется, что такой подход правильней.

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

> src всего и вся должно быть в репозитории обязательно, в этом смысл контроля версий. Иначе можно просто хранить тот же список каталог в ФС.

По крайней мере три библиотеки, используемые в проекте используются и в других проектах. Для них есть отдельные репозитории. Слышал про git submodules, но пока не смотрел.

В принципе согласен - свою плюсы есть. Но есть конкреные минусы:
- дополнительный уровень трансляции данных в rd - скрипт
- «примерно соблюдать иерархию для наглядности» - параллельно поддерживать её в двух местах одновременно? Да и перемещать бинарники тогда всё равно придётся - если в target rd этот бинарник теперь должен лежать в другом месте, то и в binaries его нужно переместить. А если соблюдать иерархию «примерно», то это всё только запутывает... так что остановился всё-таки на placeholder`ах.

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

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

В двух местах поддерживать конечно не дело, тут надо думать. Можно сделать их вообще несвязанными, типа binaries/utils/cp -> target/usr/bin/cp, тут не знаю, надо думать для твоего случая.

В hg есть аналог submodules - subrepos.

В общем, каждому свое. Я бы не хранил выходную иерархию.

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

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

В предложенном тобой варианте придётся контролировать не только скрипт, но и дерево каталогов (binaries/).

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