Системы контроля версий и кодировка имен файлов (У какой VCS нет такой проблемы?)

[Jenyay]

Привет.

Есть проект, для которого используется git. Проект пишется и под Win, и под Linux. В проекте есть файлы с русскими именами (переименовывать их нельзя). Столкнулся с очень неприятной вещью, которую в git, если и можно обойти, то только через одно место.

Суть:

1. Под Windows добавляем в репозиторий файл, в имени которого есть русские буквы.
2. Пытаемся клонировать репозиторий под Linux на раздел с ФС ext3/4. В именах файлов русские буквы становятся вопросиками.
3. Пытаемся клонировать репозиторий под Linux на раздел с NTFS. Git вообще отказывается создавать файлы с русскими буквами.

После поиска в гугле самое разумное, что нашлось - это повесить хук на post-commit, но этот вариант не нравится, потому что, если поменять кодировку имени файла с помощью convmv, то для git'а эти файлы изменяются.

Вопрос в том, есть ли VCS, в котором этой проблемы нет или она легко обходится? Хотелось бы, чтобы имена файлов, что в Linux, что в Windows из репозитория получались одинаковые (разумеется, в своей кодировке для каждой ОС).

VCS желательно распределенную, но если окажется, что у SVN такой проблемы нет, то она тоже сойдет.

[sash-kan]

если судить по концовке этого багрепорта: http://code.google.com/p/msysgit/issues/detail?id=80
то проблему windows+utf8 решили.

[Jenyay]

если судить по концовке этого багрепорта: http://code.google.com/p/msysgit/issues/detail?id=80
то проблему windows+utf8 решили.

Интересно, попробую обновить git (если еще не обновлял). Обратную ситуацию, когда файл создается в Линуксе, а читается в Винде я еще не пробовал.

[Jenyay]

Поставил последний git из исходников. Не помогло. Вот как выглядит клонирование под линуксом на ntfs-ом разделе:

jenyay@jenyay-ubuntu-10:/media/System/temp/4$ git clone /media/HANDY160/Git/test
Cloning into test...
done.
error: git checkout-index: unable to create file ��������.txt (Invalid or incomplete multibyte or wide character)

[t.t]

Возможно, я что-то не совсем понимаю (очень давно с ntfs дела не имел), но мне казалось что в Linux все вопросы с кодировками решаются на уровне монтирования, и если локаль utf-8 и смонтирован раздел с поддержкой utf-8, то выше уже проблем быть не должно по определению.

[sash-kan]

Возможно, я что-то не совсем понимаю (очень давно с ntfs дела не имел), но мне казалось что в Linux все вопросы с кодировками решаются на уровне монтирования, и если локаль utf-8 и смонтирован раздел с поддержкой utf-8, то выше уже проблем быть не должно по определению.

проблема в том, что git сохраняет (в том числе и) имена файлов as is, как их ему предоставило соответствующее api операционной системы.
соответственно, если имена файлов выходят за пределы ascii, будет несостыковка при взаимодействии. как в ту, так и в другую сторону.

Поставил последний git из исходников

там был в истории упомянутый коммит?


upd. в принципе, можно попробовать сэмулировать поведение windows, сгенерировав локаль, соответствующую той, в которой windows хранит имена файлов на ntfs. и запустить git с этой локалью. возможно, что-то получится.

[t.t]

Возможно, я что-то не совсем понимаю (очень давно с ntfs дела не имел), но мне казалось что в Linux все вопросы с кодировками решаются на уровне монтирования, и если локаль utf-8 и смонтирован раздел с поддержкой utf-8, то выше уже проблем быть не должно по определению.

проблема в том, что git сохраняет (в том числе и) имена файлов as is, как их ему предоставило соответствующее api операционной системы.
соответственно, если имена файлов выходят за пределы ascii, будет несостыковка при взаимодействии. как в ту, так и в другую сторону.

Я это писал применительно к приведенной автором топика попытке склонировать хранилище на ntfs-раздел в Linux-е. Т.е. речь о том, что, видимо, имена сохранены как-то не так уже в самом хранилище.

[deadhead]

в mercurial тоже есть такие траблы... :-(

[sash-kan]

имена сохранены как-то не так уже в самом хранилище

они сохранены «так».
я ж об этом и пишу: они сохранены ровно в том виде, как их предоставляет api операционной системы.
в windows оно предоставляет их отнюдь не в utf-8. (в приведённом баг-репорте упоминается utf-16, но память мне настойчиво подсказывает, что всё-таки в ucs-2. но спорить не буду).

[Jenyay]

Возможно, я что-то не совсем понимаю (очень давно с ntfs дела не имел), но мне казалось что в Linux все вопросы с кодировками решаются на уровне монтирования, и если локаль utf-8 и смонтирован раздел с поддержкой utf-8, то выше уже проблем быть не должно по определению.

С обычными файлами проблем нет. Тут как-то странно git себя ведет.

проблема в том, что git сохраняет (в том числе и) имена файлов as is, как их ему предоставило соответствующее api операционной системы.
соответственно, если имена файлов выходят за пределы ascii, будет несостыковка при взаимодействии. как в ту, так и в другую сторону.

Да, я вот как раз и хочется найти VCS, который бы "подправлял" имена файлов. Я себе это представляю примерно так, что в репозитории файлы хранятся в каком-нибудь UTF-8/16, а наружу он бы выдавал имена в кодировке, зависящей от системы.

Поставил последний git из исходников

там был в истории упомянутый коммит?

А вот, кстати, не посмотрел.

upd. в принципе, можно попробовать сэмулировать поведение windows, сгенерировав локаль, соответствующую той, в которой windows хранит имена файлов на ntfs. и запустить git с этой локалью. возможно, что-то получится.

Пробовал, не помогало, но это было на скорую руку, надо будет попробовать повторить более вдумчиво. И уже не помню в какой ФС это пробовал.

[sash-kan]

И уже не помню в какой ФС это пробовал.

естественно, на какой-нибудь нативной надо пробовать. в которой не будет дополнительных конвертаций (типа fat или ntfs).

[drBatty]

у меня была такая проблема (только в другой задаче), написал скрипт-костыль. Основная идея заключается в том, что-бы сделать хардлинки на все файлы, в другом каталоге, переименовав файлы в CP1251. Думаю git такое поймёт (если ему задать LANG=CP1251), единственная проблема - это если в проекте структура каталогов, причём каталоги названы по-русски.

[Jenyay]

у меня была такая проблема (только в другой задаче), написал скрипт-костыль. Основная идея заключается в том, что-бы сделать хардлинки на все файлы, в другом каталоге, переименовав файлы в CP1251. Думаю git такое поймёт (если ему задать LANG=CP1251), единственная проблема - это если в проекте структура каталогов, причём каталоги названы по-русски.

Хм, интересная идея, любопытно как git воспримет хардлинки. Главное, чтобы он их не считал новыми файлами и не пытался добавить в репозиторий отдельно.

Но на самом деле у меня еще и папки с русскими буквами.

[sash-kan]

hardlink — это и есть ссылка на содержимое файла. обычно у файла всего один hardlink. но меньше одного быть не может.

[Jenyay]

Похоже, ситуация оказалась проще, чем я думал.

Изменение локали и клонирование репозитория на NTFS ничего не дало, файлы так и не смогли там создаться, на ext3/4 gnome-console русские буквы в виндовой кодировке тоже отказался писать. Но зато konsole после переключения локали имена этих файлов без проблем показывает и работает с ними. Гугл говорит, что это не то недоделка, не то глюк gnome-console.

[Denjs]

гм...

у меня нет проблем с кодировками....
под SVN-сервер пользую свою домашнюю SuSe 10.2, локаль UTF8.
пакет USVN ставил кажется из бинарников,

под линукосом стандартный(?) SVN, под виндой - TortoiseSVN,

Каталогов русских у меня нет, но русские буквы в именах файлов проблем не вызывают.

[drBatty]

Хм, интересная идея, любопытно как git воспримет хардлинки. Главное, чтобы он их не считал новыми файлами и не пытался добавить в репозиторий отдельно.

git (как и любое по) воспринимает хардлинки как 2 разных файла, у которых содержимое одинаковое. На самом деле, это оди файл с несколькими именами. Обычный файл тоже хардлинк (это файл с одним именем. ничто не запрещает ему иметь ещё имена)

но меньше одного быть не может.

да. его система убъёт.

Гугл говорит, что это не то недоделка, не то глюк gnome-console.

да... есть там такое :(

[sash-kan]

если быть совсем точным, то второй (третий и т.д.) hardlink — это просто второе (и т.д.) имя файла. только имя.
все атрибуты файла (принадлежность, права доступа, время создания/изменения/доступа) хранятся в inode, соответственно, у всех hardlink-ов они будут идентичны.
вот не знаю насчёт acl и selinux-контекста (негде проверить сходу, а городить огород — лень). по-моему, они тоже закрепляются за inode-ом, следовательно, одни для всех hardlink-ов.

[drBatty]

если быть совсем точным, то второй (третий и т.д.) hardlink — это просто второе (и т.д.) имя файла. только имя.

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

все атрибуты файла (принадлежность, права доступа, время создания/изменения/доступа) хранятся в inode, соответственно, у всех hardlink-ов они будут идентичны.
вот не знаю насчёт acl и selinux-контекста (негде проверить сходу, а городить огород — лень). по-моему, они тоже закрепляются за inode-ом, следовательно, одни для всех hardlink-ов.

понятно что одни - ведь имя файла хранится в каталогах, потому вполне могут быть(и бывают!) файлы вообще без имён, и тем не менее, у них есть все атрибуты и свойства. Имя файла - это всего лишь ручка чемодана - чемодан может быть и без ручек вообще, или иметь их любое количество. Конечно файл/чемодан без имён/ручек дефектный, и требует ремонта. Программа лечения ФС отправляет такие файлы в /lost+found, и придумывает им новые имена.

[Portnov]

файл/чемодан без имён/ручек дефектный

Необязательно, если быть точным :) Например, безымянные пайпы - это тоже файлы :)

[Jenyay]

Оказывается, в Bazaar нет таких проблем с русскими именами файлов. Делаю из Винды коммит файла "бла-бла-бла.txt" и с таким же именем получаю файл из Linux'а на файловой системе ext3/4. В смысле, имя файла получаю в кодировке, которая установлена в текущей ОС.

[BattleCoder]

После поиска в гугле самое разумное, что нашлось - это повесить хук на post-commit, но этот вариант не нравится, потому что, если поменять кодировку имени файла с помощью convmv, то для git'а эти файлы изменяются

А как вообще в таком случае поменять кодировку через convmv? у меня похожая проблема - сделал git clone одного репозитория (который заполнялся под вендой) и вопросики в именах файлах.
Венды под рукой нет =) мне этот репозиторий просто скачать надо, а не менять в нём что-то.

Пишу convmv -t utf8 -f cp1251 -r .
он мне в ответ пишет для каждого файла (с вопросиками), что кодировка УЖЕ utf8, и переводить отказывается...

[sash-kan]

BattleCoder
так проверьте:
$ ls | iconv -f cp1251