русские имена файлов в Mercurial

Нет, они просто скажут «иди нах со своей системой контроля версий».

Нет, они просто скажут «иди нах со своей системой контроля версий».

ну патч для отдельно взятого языка написать несложно. Сделай, я-бы сделал, проблема в том, что маздая у меня нет, где я это всё тестировать-то буду? Там как-то нужно будет узнать, что мы в маздае, причём именно в русском. И когда твой патч это определит, то он должен будет все имена на входе перекодировать в utf-8, а на выходе — обратно в cp1251. Вот нагуглил тебе в помощь: https://pypi.python.org/pypi/iconv/1.0

(не пробовал. Но вроде оно)

они просто скажут «иди нах со своей системой контроля версий».

Если у них есть полномочия и возможность сказать это, они тебе так и скажут в любом случае :) Использование VCS - это поначалу всегда геморрой (и подозреваю, что в случае форматов с отсуствующим diff этот геморрой никогда себя не оправдает). Впрочем, можно попробовать SVN с DAV autoversioning.

где проверить? man virtualbox

У них полномочия сказать «ну чо ты пристал если русский язык не поддерживается». Но, он поддерживается, но лишь если ты на винде. Я о себе думаю - как лично Я такой репозиторий читать буду?

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

Хорошо, пусть даже для русского лишь только языка - workaround, не связанный с разработкой, он есть?

Хорошо, пусть даже для русского лишь только языка - workaround, не связанный с разработкой, он есть?

Я не знаю (венду вижу только со стороны). По уму, если в ней есть возможность работать с UTF-8, всё должно получиться. Конечно, в pre-commit хуке всё равно нужно проверять, что имена файлов в нужной кодировке.

Ну или можно стать героем^W^Wреализовать FixUtf8-NG или WindowsUTF8Plan

где проверить? man virtualbox

No manual entry for virtualbox

Хорошо, пусть даже для русского лишь только языка - workaround, не связанный с разработкой, он есть?

тебе уже дали три:

1. юзать раздел FAT/NTFS

2. юзать wine

3. запилить патч.

Будь мужиком, определись и сделай. Это ТЕБЕ надо, а не нам.

Вот такой он OpenSource, всякую ерунду нужную только тебе делать придётся только тебе. Увы.

Не только мне, а ВСЕМ надо чтобы был русский язык в именах файлов ;)

Вот использовать TortoiseHg под Wine - идея очень интересная. Наверное, самое предпочтительное временное решение.

И кстати, под Wine TortoiseHg действительно исправляет имена файлов? Или это предположение и мне его предстоит проверить?

Не только мне, а ВСЕМ надо чтобы был русский язык в именах файлов

нет. Только тебе. Мне например не нужно, т.к. УМВР. Я русские буквы стараюсь не юзать, но mercurial их понимает. Пруф:

$ hg log -v -r tip
набор изменений:  0:ed8e823dfee5
метка:            tip
пользователь:     я
дата:             Sat Dec 21 01:52:28 2013 +0400
файлы:            тестовый файлик
описание:
i

И кстати, под Wine TortoiseHg действительно исправляет имена файлов?

оно не исправляет, а наоборот корёжит в стиле венды. Т.е. если приложение в маздае создаст файл с именем '0xFF', получится имя 'я'. В линуксе тоже будет имя 0xFF, вот только ты прочитать его не сможешь, потому-что в utf-8 данному байту не сопоставлено символа. По определению. См. http://ru.wikipedia.org/wiki/UTF-8#.D0.9F.D1.80.D0.B0.D0.B2.D0.B8.D0.BB.D0.B0... для более глубокого изучения. В Linux требуется создать файл с именем 0xD1 0x8F, что-бы пользователь увидел имя «я».

wine естественно в курсе, и потому, перед тем, как создать файл, wine переделывает поступивший код 0xFF в правильный 0xD18F. А вот как wine определяет, что «венда» русская — я не знаю. Наверное смотрит $LANG. Тут я не в курсе. Но как-то оно определяет, ибо я проверял — WinRAR+wine+Slackware отлично работает. Твоя черепашка тоже должна, чем она хуже винрара?

Ясно, попробую.

ЗЫ У меня, разумеется, тоже русские файлы прекрасно в линуксе добавляются в репозиторий, только под виндой коробится, потому что винда = говно :)

У меня, разумеется, тоже русские файлы прекрасно в линуксе добавляются в репозиторий, только под виндой коробится, потому что винда = говно

венда не говно, а must die. Обоснование: производители маздая делят людей на категории для того, что-бы люди не могли строить и совершенствовать маздай, а могли его только покупать и плакать «запилите мне дверь». Т.е. даже если кто-нить и сделает что-нить полезное, то это полезное не взлетит у 95% юзеров. Потому-что 95% юзеров например говорят не так как я и ты, а на каких-то иных языках, с которыми мы не знакомы. Ни ты и ни я не в состоянии осилить ВСЕ языки. Даже сама мысы до сих пор не может сделать нормальную переключалку рус/лат. Сил не хватает. Русских людей, которым это нужно, просто очень мало, и мысы не может себе позволить удовлетворять хотелки очень малого процента юзеров (которых 3.5, если не считать русских халявщиков юзающих условно бесплатную венду вроде OEM, или даже безусловно бесплатную семёрку максимальную)

В самом начале, в Win95, требовалась 100%я совместимость с MS-DOS. А там имена файлов регистроНЕзависимые. В ASCII это решается тривиальным сбросом 5го бита. Про другие символы тогда никто не думал. Потому в Win95 тоже были такие имена. И в WinNT — тоже. Естественно в NT6 ничего менять не стали, ибо это невозможно в принципе. Как была cp1251, так и осталась (а в консоли 866я). Специально для русских делаются и продаются наборы костылей, которые называются в продаже «Win 7 русская». Очень удобно, ибо OpenSource не заработает ещё и по этой причине — сложно сделать поддержку Over9000 языков отдельно взятому быдлокодеру emulek'у. Увы. А надо, если я хочу, что-бы мой код был совместим с MS-DOS и выше(вплоть до восмёрочки). Потому-то я и не хочу... Такие дела...

У меня есть простой скрипт (сам писал) на Python, который обрабатывает файлы (и сохраняет их имена в файл), в том числе с русскими символами. Если этот скрипт перенести на винду и запустить работать с этими же файлами, чьи имена сохранились в файле, то оно уже их не понимает. Если я создам файл заново под виндой - то он уже понимается. т.е. 100% воспроизведение проблемы как и у Mercurial.

Может это вообще на уровне питона проблема? А на нем как известно, написан Mercurial. Разработчики не стали париться. Может там класс, который отвечает за имя файла, не переводит его в единое внутреннее представление, например в UTF-8.

Вот взять тот же Qt (особенно 5-й) - имена файлов в юникод (точно не знаю в какой, возможно UTF-8) представляются, т.е. на любой ФС и любой ОС я всегда прочту «мой файл.txt» именно так и никак иначе...

А может в Python 3.X это уже исправили???

Вот мой скрипт:

#!/usr/bin/env python
# -*- coding: utf-8 -*-


import datetime
import hashlib
import fnmatch
import os
import sys


block_size = (1024*1024)


def recursive_glob(treeroot, pattern):
    results = []
    for base, dirs, files in os.walk(treeroot):
        goodfiles = fnmatch.filter(files, pattern)
        results.extend(os.path.join(base, f) for f in goodfiles)
    return results


def get_md5(filename):
    f = open(filename, "r")
    if not f.closed:
        md5 = hashlib.md5()
        sz = os.path.getsize(filename)
        count = sz / block_size + 1
        print("processing MD5 for " + filename + " size= " + str(sz) + " count= " + str(count))

        for i in range(0, count):
            data = f.read(block_size)
            #sys.stdout.write("block size= " + str(len(data)) + " " + str(i) + "\r")
            sys.stdout.write("reading " + str(i) + " of " + str(count) + " Mb\r")
            md5.update(data)

        digest = md5.hexdigest()
        print(digest + " is MD5 of " + filename + "\n")
        f.close()
        return digest


def check_rmd5(filename):
    print("check_rmd5: checking hashes...\n")
    hashes = []
    md5_file = open(filename, "r")
    if not md5_file.closed:
        hashes = md5_file.readlines()
        md5_file.close()
    else:
        print("can't open " + filename + " ERROR")

    files_notfound = []
    files_failed = []

    count_total = len(hashes)
    count_ok = 0

    print(hashes)
    print("begin check...")
    for hash in hashes:
        t0, t1 = hash[:32], hash[34:]
        f = t1[:-1]
        print("HASH=" + t0 + "  " + f)
        if os.path.exists(f):
            new_md5 = get_md5(f)
            if new_md5 == t0:
                count_ok += 1
            else:
                files_failed.append(f)
        else:
            files_notfound.append(f)

    print("\n\n")
    for item in files_notfound:
        print("NOT FOUND: " + item)

    print("\n\n")
    for item in files_failed:
        print("FAILED: " + item)

    print("\n\nworkdir= " + os.getcwd())
    print("SUMMARY: " + str(count_ok) + " OK of " + str(count_total) + " (" + str(len(files_notfound)) + " not found, " + str(len(files_failed)) + " failed)")


def main():

    if(len(sys.argv) == 2):
        print("args count " + str(len(sys.argv)))
        check_fn = sys.argv[1]
        check_rmd5(check_fn)
        return

    print("recursive MD5 creation tool...\n\n")
    files = recursive_glob("./", "*")
    hashes = []
    for f in files:
        md5 = get_md5(f)
        print("MD5 of " + f + " is " + md5)
        hashes.append(md5 + "  " + f)

    print("\n\nhashes:")
    print(hashes)
    print("\n")

    hfn = "rmd5_" + datetime.datetime.now().strftime("%Y%m%d_%H%M_%S") + ".md5";
    print("hash filename= " + hfn)
    md5_file = open(hfn, "w")
    if not md5_file.closed:
        for hash in hashes:
            md5_file.write(hash + "\n")
        md5_file.close()

    print("end...")


if __name__ == "__main__":
    main()

Странно что это так, странно что не внутренний формат.

Может это вообще на уровне питона проблема?

Не может. У тебя в скрипте настоящее мясо. В os.walk() нужно отдавать unicode строку, тогда мб выхлоп будет содержать правильные юникодные строки (это нужно тоже проверять)

if path is a Unicode object, the result will be a list of Unicode objects. Undecodable filenames will still be returned as string objects.

Далее делаешь open(..., «w») и write(md5.hexdigest() + " " + filename + «\n»). Собственно, не возникает у тебя вопроса в какой кодировке вообще пишешь эту строку в файл? И в какой потом её читаешь.

Может это вообще на уровне питона проблема?

ниже. На уровне OS.

не переводит его в единое внутреннее представление, например в UTF-8.

не переводит. А зачем это нужно?

А может в Python 3.X это уже исправили???

ну как можно исправить глюк маздая из питона3? Ну может и можно написать костыль, который переводит кодировку в utf-8. Но такой костыль нужен только 3.5 русских маздайщиков, которые юзают Linux.

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

Собственно, не возникает у тебя вопроса в какой кодировке вообще пишешь эту строку в файл?

зачем путаешь человека? Сам нихрена не понимаешь, и другим не даёшь. Вот у меня есть байт 0xFF, «в какой кодировке я записываю в файл этот байт?». Задумайся о дебильности этого вопроса.

Проблема возникает потому, что в Windows буква «я» имеет код 0xFF, а в линуксе 0xD18F. Потому имена файлов РАЗНЫЕ. Они только с виду одинаковые также, как буква О и буква O.

Но в Qt5, опрашивая список файлов в каталоге, я получаю именно UTF-8 строку (или что там в QString), и по моему опыту, на любой ОС эта строка будет идентичной и никакие кодировки этому не помеха.

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

Тебе ниже анонимус дал очень хороший и мудрый совет. Почему ты им не пользуешься?

Но в Qt5, опрашивая список файлов в каталоге, я получаю именно UTF-8 строку (или что там в QString), и по моему опыту, на любой ОС эта строка будет идентичной и никакие кодировки этому не помеха.

ну значит в маздайном варианте оно перекодирует cp1251 (или что там, яхз) в свой внутренний вариант. Причём я даже не в курсе — какой именно. Явно не в wchar_t, потому-что по слухам в маздае они в 16 бит, и многие символы туда не лезут.

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

это не уровень ОС,

а то что платформа (в частности питон) не переводит во внутреннее, независимое от ОС, представление.

не переводит, и не должна. Имена файлов в Linux всегда НЕ переводились никуда. Даже тогда, когда были везде однобайтные кодировки. Потому мой файл из Slackware 10 будет выглядеть кракозябрами в Slackware 14. Ибо в десятке оно было в koi8-r.

Для ФС вообще нет абсолютно никакой разницы, какие именно биты в имени. Т.е. ФС плевать, как выглядит байт 0xFF. В силу того, что маленькие и большие буквы разные. Ну вот ФС и не лезет в представление имён. Ей просто всё равно.

Тебе ниже анонимус дал очень хороший и мудрый совет. Почему ты им не пользуешься?

ты упорот?

1. где это «ниже»?

2. почему ты не последуешь совету выше от анона? Он ведь по твоему «мудрый», да? А по моему — тупой.