Вышел Mercurial 1.9

> внутри Qt всё UTF-8

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

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

Не умеет. :(

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

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

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

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

Не умеет. :(

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

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

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

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

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

толсто

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

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

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

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

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

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

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

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

А можно на эти 3 строки посмотреть?

Примерно так:

for r in $(hg in -q --template '{node}\n'); do
  hg pull -r $r
done

Хехе, а если кто-то закомитит один чейнджсет на 10 гигабайт?

> Хехе, а если кто-то закомитит один чейнджсет на 10 гигабайт?

А если кто-то перережет сетевой кабель?

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

> Ну вгет-то докачает в таком случае, а хг - сфейлит

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

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

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

Все с вами ясно

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

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

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

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

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

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

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

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

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

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

вот уже 8 лет (с 2001-го года

Ну и кто здесь слоупок? У анонимуса на дворе 2009-й год...

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

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

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

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

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

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

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

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

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

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

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

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

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

> Git хотя бы сам ловит переименование файлов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Qt работает в консоли? Нет?

чего ему там не работать-то, работает

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

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

> cmd тоже не умеет работать с UTF-8

chcp 65001

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

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

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

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

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

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

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

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

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

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

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

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