QBzr

*.sql is ASCII, not binary. How do I fix this so I can see differences?

Asked by rod boggess

I have a CreateDB.sql file that SQL Server can open and execute the create an entire database with users, user access, etc. It's a text file that can (and is) edited in Notepad++. Whenever there's a change to the database, this file is updated and needs to be maintained by Bazaar. But when I run a differences, it categorizes it as a binary file and won't show differences. I don't know if this is a Bazaar issue or a TortoiseBzr issue, but I'm hoping someone on here can help me figure out how change the way it's recognized so I can see differences.

Question information

Language:
English Edit question
Status:
Solved
For:
QBzr Edit question
Assignee:
No assignee Edit question
Solved by:
Martin Pool
Solved:
Last query:
Last reply:
Revision history for this message
Best Martin Pool (mbp) said : 		#1

I'd guess you might be saving it in UCS-2, and you should choose UTF-8
in the file/save as dialog, or perhaps there actually is binary data
in it?

Revision history for this message
rod boggess (rboggess) said : 		#2

Well, I don't know how smart Notepad++ is, so I opened the *.sql file in Notepad. No squares or other indications of wide characters or binary data, so I'd say no. Any better way to verify? I don't have a save-as option that offers UTF-8 or UCS-2. But aren't both of these text, rather than binary anyway? Why would this prevent bzr from doing a differences?

Revision history for this message
rod boggess (rboggess) said : 		#3

Thanks Martin Pool, that solved my question.

Revision history for this message
rod boggess (rboggess) said : 		#4

Correction. I found in Notepad++ (this program rocks) where the encoding is saved. I still don't understand why this matters, since they are both text, but indeed it does and that fixes my problem. Thank you ever so much!

Revision history for this message
Alexander Belchenko (bialix) said : 		#5

qdiff from QBzr looking for null characters in your file, and if there is at least one, it marks the file as binary.

Revision history for this message
rod boggess (rboggess) said : 		#6

Well, that explains it. I still don't understand, but at least my lack of understanding is better informed. :)

I have to wonder if there isn't a better way to determine binary/non-binary than a null character, especially with so many encoding types using nulls for wide characters. Worse that they didn't have the foresight to allow end-users to override this default choice.

Revision history for this message
Martin Pool (mbp) said : 		#7

The problem is probably <https://bugs.launchpad.net/bzr/+bug/267296>;
this will be fixed but it's not fixed yet.

Revision history for this message
rod boggess (rboggess) said : 		#8

That looks like it exactly. Thanks. I hope the fix doesn't get dropped off as it appears to be now.