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. On Wednesday, 26 June 2019 11:11:14 UTC+1, 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. > > > > 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. > > On Wednesday, 26 June 2019 11:03:25 UTC+1, Alejandro Ariel Abaca wrote: >> >> 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? >>> >>> On Wed, 26 Jun 2019, 10:38 Alejandro Ariel Abaca via TortoiseSVN, wrote: >>> >>>> 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!" >>>>>> >>>>>> [image: Anotación 2019-06-25 074559-TortoiseSVNMerge-Problem.png] >>>>>> >>>>>> >>>>>> >>>>>> 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: >>>>>> >>>>>> [image: Anotación 2019-06-25 >>>>>> 074559-TortoiseSVNMerge-Problem-Sublime.png] >>>>>> >>>>>> >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/tortoisesvn/d79eb17f-2566-4195-ad22-309fd3e0060f%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/tortoisesvn/d79eb17f-2566-4195-ad22-309fd3e0060f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/tortoisesvn/1e32aeae-b565-4906-a7ce-819a31efd122%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/tortoisesvn/1e32aeae-b565-4906-a7ce-819a31efd122%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/eeb8784f-cd96-4313-b266-2e5ae149a4b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
