Вышел Mercurial 1.9

>эта фигня не нужна, я потратил время зря"

git не нужен?

У тебя все в порядке с головой?

Чем ветки в хг круче веток в гите?

По всей видимости ты не пробовал работать с hg всерьез, тут надо лично попробовать и убедиться. Я работал и с git и с hg, мне hg больше нравится, раз в 5 больше...

Прошу прощения за Windows.

d:\somniator\Temp>hg init u-failure

d:\somniator\Temp>cd u-failure

d:\somniator\Temp\u-failure>echo xxx > ɣ  <--- греческая гамма

d:\somniator\Temp\u-failure>dir
...
03.07.2011  14:23                 6 ɣ     <--- греческая гамма
...

d:\somniator\Temp\u-failure>hg add .
adding ?
abort: filename contains '?', which is reserved on Windows: '?'

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

Всерёз не работал, потому и спрашиваю

`--> echo xxx > γ
`--> hg addremove
adding γ
`--> hg ci -m 'Adding γαμμα'
`--> hg log -p -l1
changeset:   4:3e24699c3b06
tag:         tip
user:        nsavchenko@ivi.tv
date:        Sun Jul 03 13:29:58 2011 +0300
summary:     Adding γαμμα

diff -r 7e2ad604a001 -r 3e24699c3b06 γ
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/γ	Sun Jul 03 13:29:58 2011 +0300
@@ -0,0 +1,1 @@
+xxx

На линуксе все нормально. И гамма у тебя какая-то странная.

Проблема с кодировками имён файлов в Git тоже вроде имеется (http://unixforum.org/index.php?showtopic=116595). И там же пишут, что Bzr нормально работает.

На сколько я помню, могу заблуждаться, для Mercurial вообще не существует понятия «кодировка имён файлов».

> К сожалению, сейчас на Linux проверить не могу.

когда проверишь на Linux — разочаруешься ещё больше:

после того как ты создашь non-ascii-файл (даже хотябы НЕ с греческими символами — а просто русскими) в Mercurial под GNU/Linux — то можешь НЕ ждать что на венде при клонировании этого репозитория будут какието вменяемые имена non-ascii-файлов :-)

юникода нет! и официально разработчики Mercurial просят использовать только англисские названия файлов (или не использовать Windows :))

# p.s.: сейчас прилетят туча Mercurial-фан-боев и скажут что <вот-такое-расширение> исправляет проблему. но скажите пожалуйста — неужеле Mercurial так устроен что на каждую ЭЛЕМЕНТАРНУЮ операцию нужно накатывать своё расширение? а эти ваши чудесные расширения вообще — работает-то хоть на всех версиях Mercurial ? :-D

В общем, hg рекомендовано лучшими собаководами ;)

я бы сказал что это серьезный недостаток, не стану защищать hg тут, но плюсы перевешивают минусы...

>после того как ты создашь non-ascii-файл (даже хотябы НЕ с греческими символами — а просто русскими) в Mercurial под GNU/Linux — то можешь НЕ ждать что на венде при клонировании этого репозитория будут какието вменяемые имена non-ascii-файлов :-)

юникода нет!

А с каких пор в венде имена файлов в utf-8? По любому нужна конвертация.

> А с каких пор в венде имена файлов в utf-8? По любому нужна конвертация.

в данном случае — это не проблема самой Венды.

в данном случае — это сугубо проблема прикладной программы (Mercurial) ..
ведь никто не завставлял Mercurial хранить имена файлов в тойже самой кодировке как и кодировка операционной системы. utf-8 вполне-бы подошлабы для хранения

темболее как Python способен работать с юникодом для имён файлов ( u_name = b_name.decode(sys.getfilesystemencoding()) ) . почему эта возможность Python — не была использована?

>> эта фигня не нужна, я потратил время зря"

git не нужен?

Да. Если ты не вынужден работать с уже существующим git-проектом.

У тебя все в порядке с головой?

Да. А у тебя?

> юникода нет! и официально разработчики Mercurial просят использовать только англисские названия файлов (или не использовать Windows :))

Пруфлинк или GTFO.

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

>> юникода нет! и официально разработчики Mercurial просят использовать только англисские названия файлов (или не использовать Windows :))

Пруфлинк или GTFO.

читал гдето в http://mercurial.selenic.com/wiki/

щаз уже трудно найти (возможно на чтото более политкорретное ктото уже исправил)

...но мне вобщем то пофиг — могу эту тему и не продолжать (по просьбе «GTFO») .. сёравно ЭТО ВАМТО мучится с этой Mercurial, а не мне

I tried Git-1.7.0.2-utf8-20100725.exe from http://tmurakam.org/git/

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

А теперь впиши dir и найди там ɣ

Windows это такая гениальная система которая для консольного ПО предоставляет ДРУГОЙ API. В частности все функции работают с 8 битными cp866 или cp1251 (я уже не помню точно) кодировками.

Поэтому этот косяк будет и с git и с любой python программой в консоли. Разве, что делать хитрый клиент-сервер...

>> Пруфлинк или GTFO.

читал гдето в http://mercurial.selenic.com/wiki/

Защитан.

С юникодом только Базар по-человечески работает.

cp866

>почему эта возможность Python — не была использована?

Потому, что Python использует ту локаль с которой был запущен. Не понятно почему особенность WIndows должна так мешать? Хотите юникод? Да легко - кугвин и все работает нормально

не нужно пруфлинка, я подтверждаю это из личного опыта, к сожалению...

ВНЕЗАПНО, кодировка консоли не влияет на функции по работе с файлами. А юникодные версии тех же функций просто по определению одни на всех и ни от каких музейных кодовых страниц не зависят.

А теперь впиши dir и найди там ɣ

Читай вывод внимательнее.

d:\somniator\Temp\u-failure>dir
...
03.07.2011  14:23                 6 ɣ     <--- греческая гамма
...

С Юникодом в консоли Windows проблем не обнаружено. Я же ввел гамму и увидел гамму в выводе dir.

d:\somniator\Temp>echo x > ɣ

d:\somniator\Temp>dir
...
03.07.2011  15:37    <DIR>          .
03.07.2011  15:37    <DIR>          ..
03.07.2011  15:37                 4 ɣ
...

d:\somniator\Temp>del ɣ

d:\somniator\Temp>dir
03.07.2011  15:37    <DIR>          .
03.07.2011  15:37    <DIR>          ..

Проблема в hg.

>> почему эта возможность Python — не была использована?

> Потому, что Python использует ту локаль с которой был запущен

в каком смысле «использует туже локаль» ...

если я создам файл (в кодировке utf-8):

# -*- mode: python; coding: utf-8 -*-

if __name__ == '__main__':
    from os import mkdir

    binary_dirname = 'это просто директория (в кодировке utf-8)'
    unicode_dirname = binary_dirname.decode('utf-8')

    mkdir(unicode_dirname)

...то почему этот код будет *корректно* работать в операционной системе где локаль windows-1251 (а не utf-8) ???

что мешало Mercurial поступать также? %) %) %)

У ревью-боарда не слишком удачная идея организации ченджсетов.

Хых, от шестисот до штуки в месяц на поддержание штанов - дороговасто будет

> При переименовании файла в Mercurial фактически происходит удаление+добавление, так что места требуется O(N) (в git - O(1)).

Ох, ё! серьёзная заявка на успех.

> Чем ветки в хг круче веток в гите?

Ну, в принципе, ничем. Но за счёт «интерфейса» работа с бранчами осуществляется более SVN-подобным образом, что многие находят более привлекательным, чем то как это сделано в git. Впрочем, git-new-workdir из git contribs позволяет организовать нечто подобное и c git.

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

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

>Да. Если ты не вынужден работать с уже существующим git-проектом.

Есть один небольшой «существующий git-проект». Линукс-идро называется.

А зачем создавать файло на русском языке?

Это уже другой вопрос (: я сам не понимаю, где в проекте могут понадобиться файлы с русскими именами.

Ну разве что если vcs используется не для кода, а для каких-то других личных файлов.

Да, похоже, без fixutf8 не обойтись.

>> При переименовании файла в Mercurial фактически происходит удаление+добавление, так что места требуется O(N) (в git - O(1)).

Ох, ё! серьёзная заявка на успех.

А что, тебе часто требуется переименовывать большие (> 1М) файлы?

SourceSave всё: http://vssisdead.com/

Здорово. Надо обновиться.

Всем выше высказавшимся на счёт «закопать SVN» желаю хотя бы один раз поработать с VSS.

Я сам hg пользуюсь как «улучшенным SVN», т.е. в режиме - commit + push, pull, update, и пара команд для статистики, ветки не создаю и не сливаю, над диффами не медитирую.

p.s. Пользователь VSS... (тут матом). В итоге всё закончилось написанием своего клиента этой СКВ для проекта.

> желаю хотя бы один раз поработать с VSS.

а что в нем такого ужасного? жажду подробностей.

>сабж - пестоноподелка. Его в принципе нельзя использовать в серьезной работе.

Очень аргументированно. Очень. Аргументов прямо целый ноль.

Unicode в именах файлов до сих пор не поддерживает? Windows

Если бы не начал читать комменты к этой новости, то ни за что бы не узнал о данной проблеме. Тесно работаем с сабжем уже джва года.

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

Мне - нет. Но у меня, строго говоря, вообще нет таких файлов в VCS. Неприятен сам принцип складирования данных, честно говоря.

Из Википедии: «Visual SourceSafe's stability is criticised due to the way Visual SourceSafe uses a direct, file-based access mechanism that allows any client to modify a file in the repository after locking it. If a client machine crashes in the middle of updating a file, it can corrupt that file.»

Из Интернетов: http://www.highprogrammer.com/alan/windev/sourcesafe.html

Missing Features:

SourceSafe lacks usable branching support

SourceSafe cannot be safely extended

SourceSafe silently leaves stale files on your local system

SourceSafe badly handles slow networks and the public internet (это просто нереальный пипец...)

Managing third party modules is difficult with SourceSafe

Viewing and retrieving historical versions is extremely slow

Difficult to maintain multiple local copies of one project

Safety:

SourceSafe degrades on large projects

SourceSafe integration can crash Visual Studio

SourceSafe relies on dangerous file sharing

SourceSafe should be scanned for corruption weekly

SourceSafe handles multiple time zones badly

SourceSafe becomes corrupted

Я мог бы перевести...

Но честное слово, если вы никогда с ним не столкнётесь - это будет неплохо. Система контроля версий, которая работает не по принципу клиент-сервер, единственным вариантом работы с которой является Lock/Unlock (ChekOut/CheckIn), не умеет «мёржить» файлы, в начале 20-х годов двадцать первого века является анахронизмом и подлежит забвению.

Как вендузятнег (и латентный линупсист гыгы :) ) долго юзал svn. Когда поднялся шухер с DVCS, спокойно продолжал юзать svn - просто потому, что для наших задач никакого «распределённого версионинга» не нужно. Думаю, что и у многих из вас DVCS - только дань моде.
Когда всё же решил (на будущее) освоить какой-нибудь из них, Mercurial показался самым простым - и встало на ура, и туториалы были наглядные, и работа с черепашковой помощью была одними кликами - верх простоты. Мне кажется, все эти войны не стоят и гроша, если юзер не может осилить какой-то пакет - всё должно быть просто, а если это не просто, то это кал.

Проблема с UTF-8 высосана из 21 пальца. За столько лет, да ещё и с исходниками, просто не приходил в голову такой бред - юзать не английский в именах.

А размеры репозитория... да ерунда это - когда ДОМАШНИЕ винты исчисляются терабайтами, просто смешно обсуждать какие-то мегабайтные отличия. Особенно если это ускоряет работу.

>Очень аргументированно. Очень. Аргументов прямо целый ноль.

пестоноподелка.

>Думаю, что и у многих из вас DVCS - только дань моде.

нет. Ты просто не прочувствовал суть изменений.

Она вовсе не в какой-то мифической децентрализации. Суть в том, что теперь у каждого разработчика есть свой репозитарий прямо тут, на том же диске. Поэтому он всегда доступен для преименований, коммитов, дифов, логов и все такое.

Фактически, это умная локальная файловая система. Доступно и функционально даже в ноутбуке на необитаемом острове.

И вместе с тем можно добавить центральный репозитарий и в любой момент синхронизироваться с ним. Отправлятть изменения, принимать их, сливать, клонировать и все такое.

Получается удобная и надежная система, которую можно использовать для кучи вариантов, которые с svn раньше не работали или были слишком сложны. Например, удобное управление репозитариями. Каждый реп отвечает за свою архитетуру. Спек обновил, push в один реп и пакетик собрался, или во все, тогда пересобрался везде. Или деплой проекта на сервер. Удобнейше даже для одного разработчика.

Ох, ездил на дачу и пропустил тему, которую ждал. Дело в том, что к этому релизу я сделал перевод всех встроенных хелпов ртути. Я знаю, что это не нужно почти никому и я знаю, что перевод получился полное говно. Но я хотел бы, если здесь есть кто-нибудь заинтересованный, обсудить где-нибудь перевод терминов (changeset, head, push - ужас просто), ну и конечно принимаю патчи, бандлы и даю пуш-аксесс на BitBucket.

Bazaar, кто за базар отвечает?

Vault кстати немногим лучше SourceSave. :)

> Windows это такая гениальная система которая для консольного ПО предоставляет ДРУГОЙ API. В частности все функции работают с 8 битными cp866 или cp1251 (я уже не помню точно) кодировками.

Никакого другого API нет, для всех приложений есть две версии API:

Одна с cp1251 (или другой однобайтной кодировкой).
Вторая юникод в виде UTF-16.

Поскольку все программисты привыкли писать char* то обычно выбирают первое и следовательно никакого вам юникода.

Стоит отметить, что хорошая либа решает такую проблему.
В Qt например хорошо сделано: внутри Qt всё UTF-8, но при вызове вендового API конвертится в UTF-16.
В gtk/glib такой же подход.
Python 2.x в данном случае хорошей либой не является и эту проблему никак не решает.