Replies: 6 comments 33 replies
-
You have to consider the twinproj file as a virtual file system. It's like a zip file. There are good reasons that the twinproj file format is not text based, in the same way that there are good reasons ZIP files, VDI files etc are not text based. The decision mostly comes down to efficiency, and serialization simplicity. There is also meta-data that does not lend itself well to text-based storage, such as indices. Soon, you'll also be able to include binary files such as graphics inside the twinproj file once the one-file limit has been removed. When thinking of SCC, you wouldn't diff a ZIP file, and so you wouldn't diff a twinproj file. You'd diff the extracted content, and once we support SCC from inside VS code, that's exactly how it'll work with tB projects. If the twinproj file wasn't a self-contained virtual file system, then a text-based human readable file format would likely have been chosen. |
Beta Was this translation helpful? Give feedback.
-
I must say I agree with the original poster, dealing with binary files in source control is a pain in the bum. There's nothing more frustrating that .frx files changing and you have no idea why. I also think it's pretty standard these days for projects files, and many many other files developers have to work with to be humanly readable, but even more importantly to be comparable and easily differenced. What about when you have to do merges between people adding new files to a project, or as you say images but with the same file names? People are even choosing to work with svg files more because of these features. |
Beta Was this translation helpful? Give feedback.
-
It sounds like the twinproj file is almost like a local cache, rather than the 'master record'. (Except for project metadata which doesn't seem to have any text-only equivalent that would be able to be source controlled?) So why make the twinproj file user-visible at all... if its just needed for efficiency. This would be something like the .vs directory which Visual Studio creates when you work on a C# or other .NET solution, but ultimately can be totally discarded and rebuilt when needed, the user doesn't concern themselves with it. |
Beta Was this translation helpful? Give feedback.
-
Fully agree ! Would make it way more easy to migrate things between vb6 vba and TB. As a first step it would be a help if the file extnesions would be same as in Vb6. To just name all .twin is unhandy and you can not just throw files around. Also The Module and Class statemenst should be hidden. Its unhandy by copy and paste a whole module. Even if the project file isnt VB6 compatible. its easy to create just a tb project export ist and create a new VB6 project with the exported files imported. In this case you has what you want (at least half the way) - one code base (tb) but you can see without a lot of work how the "original" would behave. Which might also a nice timesaver to track problems down ;) |
Beta Was this translation helpful? Give feedback.
-
This discussion seems like an X/Y issue. Most of the desire to have human readable files seems to be around git and source control. I'm sure you've considered this @WaynePhillipsEA so can I ask what is your latest vision for source control support? I think if that is clear then most of this discussion is moot. Re-reading the other posts in this discussion I see 3 options (not necessarily exclusive, multiple alternative options could be supported at once if there is no single "Right Way"):
Additional Context: These could be worked in as IDE plugins if the IDE supports scripting. Or as Language Servers. Both those methods work with a virtual filesystem (LSP is |
Beta Was this translation helpful? Give feedback.
-
I still think to implement something compatible to VBx would be the simplest and most flexible solution. Its also the most robust ones. If something weired happens you do not loose everything :) And a lot of code tools alredy written will have a chance to still work on :) There are reasons why all compilers i know relay on simple ascii files ;) Some kind of packing system might be a idea to archive things. But that would be on top. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem?
Modern source control systems expect to deal with non-binary files. Their diff tools are set up to optimise for this convention.
Describe the solution you'd like
Either JSON, XML, or (even) INI project files.
Additional context
Currently, twinBASIC uses:
.Net (with the .Core reset) has moved to minimal, convention-based project files, expressed in XML form. This decision made it much easier to diff commits and critique any changes made (as there was much less boilerplate).
VB6, for all its faults with indeterministic serialisation, tended to keep with renderable file formats, except for binary resource files. Everything except .**x files could be diffed for source control.
Using a binary project file seems like a step backwards.
Beta Was this translation helpful? Give feedback.
All reactions