Some .resx files in a c# solution do not work in TortoiseMerge

[Alejandro Ariel Abaca]

Hello.

I have a pretty large solution written in c# involving a project containing GrapeCity ActiveReports. The reports are c# classes that have .resx files attached. We are VC against VisualSVN using Tortoise and sometimes have problems with some of the .resx files when we want to compare the text file in the repo with the file in out local copy of the repository. The exact error is "The file <path-to-a-temp-file-in-my-profile-directory>.resx is not a valir TextFile!"

The image shows that the file is, indeed, a text file and It can be open with the (basic) Notepad app from Windows 10. But when I open the same file with my copy of Sublime I found out that after the closing tag (the .resx file is an XML document), there are a number of CHAR(0) characters, as in the following picture:

So my guess is that the merge code is taking those CHAR(0) into account for resolving my repo file si not valid. Is there something I can do to resolve this Issue? Maybe there is a configuration that can be done that I do not know that can help. Otherwise, can Tortoise Merge forgive those CHAR(0) characters after the closing XML tag as they do not have any meaning out there?

Thanks in advance.

From Argentina.

Ariel.

[Oskar Berggren]

I think the question you need to ask is where these null bytes come from. I've never seen that behavior in resx before.

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/d79eb17f-2566-4195-ad22-309fd3e0060f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alejandro Ariel Abaca]

I do not know exactly where they come from, but I have a theory: those files are generated from the GrapeCity ActiveReports designer itselft. I create a new report class for a new report and, only in some of the new clases, the .resx report contains those null bytes.

Anyway, I would like the merge app to handle this files as they are not really 'not a text file' as I can open them in the Notepad editor. So, the question stands. Can I do something to change the behaviuor of the program when reading this files?

Thanks in advance.

Regards.

Ariel.

El martes, 25 de junio de 2019, 14:06:59 (UTC-3), Oskar Berggren escribió:

I think the question you need to ask is where these null bytes come from. I've never seen that behavior in resx before.

On Tue, 25 Jun 2019, 11:55 Alejandro Ariel Abaca via TortoiseSVN, wrote:

Hello.

I have a pretty large solution written in c# involving a project containing GrapeCity ActiveReports. The reports are c# classes that have .resx files attached. We are VC against VisualSVN using Tortoise and sometimes have problems with some of the .resx files when we want to compare the text file in the repo with the file in out local copy of the repository. The exact error is "The file <path-to-a-temp-file-in-my-profile-directory>.resx is not a valir TextFile!"

The image shows that the file is, indeed, a text file and It can be open with the (basic) Notepad app from Windows 10. But when I open the same file with my copy of Sublime I found out that after the closing tag (the .resx file is an XML document), there are a number of CHAR(0) characters, as in the following picture:

So my guess is that the merge code is taking those CHAR(0) into account for resolving my repo file si not valid. Is there something I can do to resolve this Issue? Maybe there is a configuration that can be done that I do not know that can help. Otherwise, can Tortoise Merge forgive those CHAR(0) characters after the closing XML tag as they do not have any meaning out there?

Thanks in advance.

From Argentina.

Ariel.

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.

To unsubscribe from this group and stop receiving emails from it, send an email to torto...@googlegroups.com.

[Oskar Berggren]

A file is a sequence of bytes. If it contains characters typically not found as part of normal text, then it is not a text file. That notepad can read it doesn't prove much, bytes are bytes.

I wonder if you can trick the merge program by setting svn mime type but I'm not sure it will look at that. The feature you are looking for I suppose is "treat all files as text" but I'm not sure if there is such a setting.

Have you reported the bug in the program that generates the faulty files?

A script to remove the extra bytes perhaps?

To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/1e32aeae-b565-4906-a7ce-819a31efd122%40googlegroups.com.

[Alejandro Ariel Abaca]

I can understand what you mean with the concept of text files. Then I can ask why the commit command does indeen commit a file with this (bad) format when later other code in the same solution will not be able to use that commited file. I mean if the file is not a text file, then it is not for any programs. Right? I Will try to contact the reports provider. But, as I have stated, I have a number of this files already commited in my SVN repository. I would like to fix those issues too.

Thanks for taking the time to answer me.

Ariel.

El miércoles, 26 de junio de 2019, 6:46:51 (UTC-3), Oskar Berggren escribió:

A file is a sequence of bytes. If it contains characters typically not found as part of normal text, then it is not a text file. That notepad can read it doesn't prove much, bytes are bytes.

I wonder if you can trick the merge program by setting svn mime type but I'm not sure it will look at that. The feature you are looking for I suppose is "treat all files as text" but I'm not sure if there is such a setting.

Have you reported the bug in the program that generates the faulty files?

A script to remove the extra bytes perhaps?

[Bruce C]

This isn't an answer but a pointer that might help.

 

The resx files generated by Visual Studio are xml files, encoded as Unicode UTF-8. Depending on the content, this may includes bytes that would normally be considered as control characters (e.g. NUL, 0x00). When I use the TortoiseSVN Diff tool on a resx file it does seem to have status bar information that suggests it supports Unicode. In fact, the encoding used can be changed from here too. However, you may have to give teh diff tool a prompt about the file encoding by setting a Subversion property for the file.

 

Have you looked at the svn:mime-type property? This is a Subversion property to define the content of the file. I haven't used this myself but a setting of text/xml; charset=utf-8 might be appropriate.

 

If this works, you might also want to review the Subversion auto-props capability? This allows the svn:mime-type property to be automatically set, when a file is added, according the file extension.

 

As an aside I note that I have resx files that are encoded as UTF-8 but don't have the BOM (Byte Order Marker). However, the same project has cs files that are also encoded as UTF-8 but do have the BOM. That seems like an odd inconsistency.

 

I haven't tried these things but perhaps it might be an area for you to investigate.

 

Hope this helps.

[Oskar Berggren]

Subversion is perfectly capable of handling any file. Why would it be limited to text files only?

The merge operation is different because text files can often be merged without destroying the content. Even if it causes invalid syntax, it's generally easy to fix afterwards. If you try to merge two versions of a real binary file, it will generally lead to an invalid file that cannot be processed by any common program designed to operate on that file format. Detecting if a file is binary is simply checking if the file contains any byte not normally used for text. A null byte is most definitely such a byte.

It is up to each program to define how much they care. You can open any file in notepad, even an exe, because it simply doesn't care that much.

If the designers of that other program believes this is a feature or an acceptable behavior of their program, they are making a mistake, precisely because of this effect on merge.

It looks like they keep the file contents in an internal oversized buffer and then write the entire buffer to disk instead of stopping at the first null byte. Probably it's a bug, and not an intentional design.

To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/475302c0-07e6-4bd9-bcf5-b32ed85f21a0%40googlegroups.com.

[Bruce C]

Actually, if I might correct myself, I don't think that UTF-8 encoding can include the NUL (0x00) value as a side-effect of encoding as I used as an example. If the NUL character is in the file, it would be unchanged by UTF-8 encoding.

The point remains that the encoding may be relevant - it's simply the specific encoding example I used that's wrong.

[Bruce C]

Looking more carefully at the screenshots attached to the original report, I note that the first does show that the file may be encoded as UTF-8. However, the second screenshot does suggest that the file has been appended by unnecessary NUL characters that are nothing to do with the encoding.

I would agree with you that the latter seems more likely to be the cause of problems.

Apologies for not having looked more carefully before posting and potentially confused things (although better definition of the encoding would do no harm).

[Alejandro Ariel Abaca]

Everything you have written, I understand very well. If my original files are bad text files, I can commit them and the SVN server saves then in a format that is marked as not text file. Then, when I try to compare one of those files against my local copy, the error I have written about appears. I have seen several times that, if I commit the local version of one of those files again, the problem dissapears (I can make a difference from THAT commit on). So, I wonder if there is a way for me to find out those commited files that are not valid text files in the SVN server and make a manual replacement of the tail nul characters for nothing to convert those files in valid text files. Do you have information on how to do that? Maybe a link to a help page would help.

Thank you very much for taking the time to answer.

Regards.

Ariel.

[Oskar Berggren]

Here's some ideas:

https://stackoverflow.com/questions/567757/how-do-i-distinguish-between-binary-and-text-files

Perhaps SVN set a binary mime-type on them when you first added them (svn property) so you could try to look for that also perhaps.

/Oskar

--

You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/58a04889-c58d-4f25-bb6e-32486bd61c12%40googlegroups.com.

[David Balažic]

On Wednesday, 26 June 2019 12:11:14 UTC+2, Bruce C wrote:

This isn't an answer but a pointer that might help.

 

The resx files generated by Visual Studio are xml files, encoded as Unicode UTF-8. Depending on the content, this may includes bytes that would normally be considered as control characters (e.g. NUL, 0x00). When I use the TortoiseSVN Diff tool on a resx file it does seem to have status bar information that suggests it supports Unicode. In fact, the encoding used can be changed from here too. However, you may have to give teh diff tool a prompt about the file encoding by setting a Subversion property for the file.

 

NUL (and some other control characters) are forbidden in XML.

If a file has them, then it isn't a (valid) XML file/document.

Regards,

David

[Stefan]

On Thursday, June 27, 2019 at 12:00:39 PM UTC+2, Oskar Berggren wrote:

Here's some ideas:

https://stackoverflow.com/questions/567757/how-do-i-distinguish-between-binary-and-text-files

Perhaps SVN set a binary mime-type on them when you first added them (svn property) so you could try to look for that also perhaps.

Seriously? You're telling me how to code by searching stackoverflow?

Very insulting....

[Oskar Berggren]

I'm not so sure where this misunderstanding comes from, but this was in response to when Alejandro Ariel Abaca asked for ideas on how to find the files with this problem in his repository. It thought that page had some relevant suggestions.

Best regards,

Oskar

 

--
You received this message because you are subscribed to the Google Groups "TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tortoisesvn...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/a62aeca2-8f95-4cb2-af89-ad6abcedbc0c%40googlegroups.com.

[Alejandro Ariel Abaca]

I'm sorry for having created such a discusión. My intended request was if there is a way for me to modify those "bad" textfiles in the repository. I mean, find them in the repository database and replace those entries with the "correct" file. Can I do that in any way?

Thanks in advance.

Regards.

Ariel.

El jueves, 27 de junio de 2019, 12:43:22 (UTC-3), Oskar Berggren escribió:

Den tors 27 juni 2019 kl 15:23 skrev Stefan via TortoiseSVN 

On Thursday, June 27, 2019 at 12:00:39 PM UTC+2, Oskar Berggren wrote:

Here's some ideas:

https://stackoverflow.com/questions/567757/how-do-i-distinguish-between-binary-and-text-files

Perhaps SVN set a binary mime-type on them when you first added them (svn property) so you could try to look for that also perhaps.

Seriously? You're telling me how to code by searching stackoverflow?

Very insulting....