Perché Mercurial pensa che i miei file SQL siano binari?

Question

Ho appena creato script per i processi, le definizioni di tabella, ecc. Di SQL Server utilizzando SQL Server Management Studio e ho provato ad aggiungerli al mio repository di controllo del codice sorgente Mercurial. Sono stati aggiunti alla perfezione, ma ora quando li cambio e li diff, Mercurial li chiama "file binari" e non mi dà una copia unificata corretta.

Pensavo che la codifica potesse essere un problema, quindi ho provato a rigenerare gli script e specificare ANSI per l'output del file di testo, ma ottengo lo stesso comportamento. Riesco a vederli bene nel blocco note senza che si vedano personaggi dall'aspetto strano. Perché Mercurial pensa che questi file siano binari?

Altrimenti, se qualcuno può consigliare un buon strumento per lo scripting di un database SQL Server che potrebbe non causare questo problema, potrebbe funzionare anche.

Answer 1

Ho incontrato questo problema perché SQL Server Management Studio salva i file come Unicode. I primi due byte (la maggior parte delle volte) di un file di testo Unicode definiscono la codifica. I più recenti editor di testo (ad esempio Blocco note) gestiscono questo in modo trasparente.

I primi due byte sono probabilmente il problema. Possono sembrare ÿþ. Oppure FF FE in esadecimale.

Il pulsante "Salva" nella finestra di dialogo Salva è un elenco di selezione. Scegli "Salva con codifica ..." e seleziona "US-ASCII-Codepage20127". Credo che questa impostazione sia appiccicosa e rimarrà per salvataggi futuri.

Answer 2

Secondo the docs, è considerato binario se ci sono byte null nel file. I file SQL non dovrebbero avere byte null, quindi dovrei controllarlo prima (prova a cercare in un editor esadecimale). Presumo che tu sappia che puoi forzare diff per trattarlo come testo

Answer 3

Andrew ha ragione; è un byte NUL da qualche parte (la mia ipotesi sarebbe un Byte Order Mark all'inizio inserito da uno strumento editor maleducato). Non ti preoccupare però, a differenza di SVN o CVS Mercurial non gestisce affatto il binario rispetto al testo. Lo visualizza diversi quando si esegue "hg log", ma non vengono gestiti in modo diverso.

Le mercurial imminenti rilasciano distorsioni di casi speciali e non consentono loro di attivare il comportamento di "utente probabilmente non vuole vedere un diff di questo su console".

Answer 4

Mi sono imbattuto in questo durante la modifica di un file di stored procedure da SQL Server su Linux e utilizzando git. Git pensava che fosse un file binario perché il file di SQL Server era UTF-16 e quindi conteneva NUL. La mia correzione per questo era emacs, che ti permette di cambiare la codifica in UTF-8.

Answer 5

So che è un po 'tardi, ma mi è venuto in mente uno script per salvare in batch i file * .sql in UTF-8.

La risposta completa viene pubblicata in un'altra discussione su StackOverflow, quindi inserirò il link qui - https://stackoverflow.com/a/9743360/336079.

Answer 6

Ho avuto un problema simile e ho deciso di utilizzare uno strumento trovato a http://www.devio.at/index.php/smoscript per aiutarmi a risolvere il problema. Ho copiato SMOscript posizionando quanto segue in un file 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 

L'idea è di rimuovere la vecchia cartella in modo che tutti gli oggetti eliminati dal database vengano eliminati dal controllo del codice sorgente. Questo salva anche i file come UTF8 senza alcuna data/ora, quindi funzionano molto bene nel controllo della versione.