@mansellan we just dealt with a tricky of issue stemming from the way VBA modules are exported from the host when using .SaveAsText. We had some edge cases where source files would show bizarre changes and it was due to the diff tool guessing the wrong encoding.
What we ended up doing was taking that output and converting the encoding to UTF-8 before it's checked in to source control. We had to pull the current codepage at export time and use that in the encoder as the source. This avoids ambiguity about what the system codepage was at export and failures to detect the encoding by git\diff\merge\editors.
I'm not sure how RD handles exports but it looks to me like it's not changing the export format at all.
I don't think we can safely do so as we wouldn't have the encoding information when importing.
we can infer the encoding used at export time but then we have to store that metadata somehow for future imports on another system. No that doesn't matter if we use UTF-8. Nevermind.
LoL. I keep seeing OASIS being mentioned. I've never used it but I believe the open source project I am working on is just following in their footsteps.
Don't get me wrong - I think the format that's used by SaveAsText is fugly and it has lot of stupid stuff that makes it less than ideal for SCC but I've also worried that if you change the structure (even just to sort the list of properties alphabetically for example) it could have unintended consequence.
Yes. It's a big bane and the most inane thing to put in SCC
It's one thing if the report was configured to use a specific printer but that is rare. Even for reports configured to use default printer, WE. MUST. EXPORT. ALL. THE. PRINTER. DATA. FOR. THE. SAKE. OF. THE. HUMANITY!!1!