Почему Mercurial думает, что мои SQL файлы являются двоичными?

Я просто написал сценарии, хранящиеся в SQL Server, обработанные procs, определения таблиц и т.д., используя SQL Server Management Studio, и попытался добавить их в мой репозиторий управления ресурсами Mercurial. Они добавлены просто отлично, но теперь, когда я меняю их и меняю их, Mercurial называет их "двоичными файлами" и не дает мне надлежащего унифицированного diff.

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

В противном случае, если кто-то может порекомендовать хороший инструмент для написания базы данных SQL Server, которая может не вызвать эту проблему, это тоже может работать.

Ответ 1

Я столкнулся с этой проблемой, потому что SQL Server Management Studio сохраняет файлы в формате Unicode. Первые два байта (в большинстве случаев) текстового файла Unicode определяют кодировку. Большинство новых текстовых редакторов (например, Блокнот) обрабатывают это прозрачно.

Первые два байта, вероятно, где ваша проблема. Они могут выглядеть как ÿþ. Или FF FE в шестнадцатеричном формате.

В диалоговом окне "Сохранить" в диалоговом окне "Сохранить" отображается список выбора. Выберите "Сохранить с кодировкой..." и выберите "US-ASCII-Codepage20127". Я считаю, что этот параметр липкий и останется в будущем.

Ответ 2

Согласно docs, он считается двоичным, если в файле есть нулевые байты. SQL файлы не должны иметь нулевых байтов, поэтому сначала я должен проверить это (попробуйте посмотреть в шестнадцатеричном редакторе). Я предполагаю, что вы знаете, что можете заставить diff обрабатывать его как текст

Ответ 3

Эндрю прав; это где-нибудь в байте NUL (моя догадка была бы Byte Order Mark в начале, введенном грубым инструментом редактора). Не беспокойтесь об этом, хотя, в отличие от SVN или CVS Mercurial не обрабатывает бинарные файлы по-разному. Он отображает их разные, когда вы делаете "hg log", но они не обрабатываются совсем по-другому.

Предстоящие меркуриальные выпуски специальных спецификаций случая и не позволяют им запускать "пользователь, вероятно, не хочет видеть, как это происходит на консоли".

Ответ 4

Я столкнулся с этим при редактировании файла хранимых процедур из SQL Server на linux и с помощью git. Git думал, что это двоичный файл, потому что файл с SQL Server был UTF-16 и поэтому содержал NUL. Мое исправление для этого было emacs, которое позволяет вам изменить кодировку на UTF-8.

Ответ 5

Я знаю это немного позже, но я придумал script для пакетного сохранения *.sql файлов в UTF-8.

Полный ответ отправлен в другой поток на StackOverflow, поэтому я просто отправлю ссылку здесь - fooobar.com/questions/115869/....

Ответ 6

У меня была аналогичная проблема, и я решил использовать инструмент, найденный в http://www.devio.at/index.php/smoscript, чтобы помочь мне решить проблему. Я написал SMOscript, поместив в файл cmd следующее.

rd /s /q [the scripts folder]
"C:\Program Files\devio IT Services\SMOscript\smoscript.exe" -s [server] -d [database] -F [the scripts folder] -U

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