Project format

Who is using text format and who is using binary when saving Xojo projects?
And why?

I’m mostly using the text format as it plays nicely with VCSes. I’ll use the binary format for bug tickets or when I need to pass around a project to someone as it’s easier than dealing with a .zip.

1 Like

Being able to see the history of changes to my code in all different places is priceless.

If you want to open source something is a must.

I learned about version control and Git from a recommendation from this forum even as a solo programmer for hobby projects.

Now that I use project/text format I won’t go back to binary if I can avoid it.

I use xml. Text format is not useful when sharing project items between different projects.

1 Like

That’s interesting. That was one of the big reasons for making many projects binary.
Are you saying that you can reference external project items if they are XML?

That’s what we do. Shared items between projects are in XML format. Otherwise we use the text format for everything.

XML stinks for code reviews, though, since it shows all the XML in addition to the parts you want to actually see.

1 Like

in my experience, xml project is slow at read/write.

To get the whole code in a single file, I print the project (no item selected in the navigation pane) to pdf and deal with that in Preview (MacOS). I get a copy of the windows images too.
Was useful as backup (coincidence) a day I trashed (lost ?) a project and needed to update the last saved who was some days old.

Now, everybody is free to do what they want. :wink:

That’s what Arbed is for.

Text, for use with GIT or SVN etc.

Text Project Format. Always.
Along with either SVN or Git.

And we use shared items with Text Project Format, too.
Works great for us with a MonoRepo: Xojo Projects in a MonoRepo – Xojo Programming Blog

1 Like

I guess everybody can reuse code in text without the mess of putting multiples different projects into a single repo.

I did not investigate, but I guess having a shareable “library” project with proper shareable items in place, and creating mimics of the structures involved in other projects, saving, closing, and then replacing the files and folders by links to the real contents in the shared places would do the job.

UPDATE: I did a fast test and links does not help… but… I could make a folder in a shareable lib project being used correctly in another project. So it works. I was just doing a fast PoC so I did not care much about the steps and creating garbage while experimenting. So, yes, it can be done in text. Someone with some spare time can go further, investigate more deeply, and make a proper tutorial.

I had a major GIT catastrophe once and I’m always nervous now.
I have a very elaborate backup system that should keep me safe unless the world comes to an end.

I was also worried about speed impacts of XML format.

That doesn’t really help in our company tool and workflow with multi-user code reviews.

Text so I can use Cornerstone to examine the history in a convenient way. Cornerstone uses Subversion internally.

Obviously you should have backups as well. Text is easier to identify and rescue if all else fails.

I use text format and Git repository as VCS. This allows dev work and deployment in test/prod environments.

I used to only use text format for projects (and XML for External Items), but since I retired, I can only afford the Mac “Lite” license and save in binary format.

I’m actually quite happy with the binary format because it’s fast and when coupled with the Arbed commandline features, I can automate a text based backup that allows me to also see my changes in GitHub Desktop just fine.

Bonus: the XML source backup from Arbed has much more readable diffs than the standard Xojo XML files.

1 Like

I’m always using the binary format.

I recognise the project icons right away and the binary format is fine for me.

1 Like

I use binary format because it is self-contained and compact. I use SVN for source control and I developed an arbed-like diff utility in house.


I use Binary since I don’t need to share code and I do offsite backups nightly.