My question is what makes the projects you save in desktop lite not version control ready? Does it not let you save in the text project format and force you on to binary files?
Thanks
You can’t save in the Text format.
Not using text format for version control makes no sense
Version control is basically essential for teams. If you want to prevent the situation where 10 developers use the free or lite version and only one uses Pro to compile then the free and lite version must not support version control, therefore no text files.
I’d say it’s basically essential even if you’re a lone developer though 
Being able to revert to earlier revisions is priceless!
I have used external items with a main project in the last years with version control. No problems at all.
The big - no huge - problem with version control is that it doesn’t easily allow items in multiple projects. When I want to change from binary/xml to text I have to redo all my projects and the complete build sequence because the paths will change.
Oliver,
even with google translate does not let me understan your question. The default save version for all versions is Binary. If you buy a license, you will be able to save the project as Text (VCP) and xml.
Care to explain (differently) what you want to know ?
Emile, basically Oliver is asking
Does the Free/Lite version of Xojo save in Text format so I can use Version Control?
The answer of course is, NO
Short answer: Yes, exactly.
You can still use a sourcecontrol system like Git to be able to revert to different stages but you wont be able to see what the changes are (except for your comments included in the commits).
I think Arbed will compare binary projects. I wrote an app that I use internally to compare binary projects and show the diffs. I have thought on occasion about making it available for sale if there is any interest.
[quote=290233:@Albin Kiland]I’d say it’s basically essential even if you’re a lone developer though
Being able to revert to earlier revisions is priceless![/quote]
Easily done by saving versions 
MyProject 161003
MyProject 161004
MyProject 161005
Etc
time machine and a rcent operating system (on a mac) will let you do version control completely transparent and efficient too.
There’s no problem checking in binary files to version control, or checking them out. However, you can’t easily see the changes with a diff tool as you would with textual file formats, either when you check in a revision or when you compare different revisions. The only way to see the changes is to check out each revision’s binary project file and open it up in Xojo… but even then, the changes might not be obvious.
Personally, when I’m about to check in a revision, I use the diff tool to see what I changed in each file. This helps me tremendously as I write the comment for the commit. For me, a text format is essential for version control.
[quote=290345:@Markus Winter]Easily done by saving versions 
MyProject 161003
MyProject 161004
MyProject 161005
Etc[/quote]
No not even close! You are missing all the tooling that allows you to be productive when working with versioning.
What I meant by ‘Lite’ was the cheapest license not the free version. It is listed as ‘Lite’ in the comparison chart. Just to clarify. It seems like the ‘Lite’ version is not very good option to buy tbh. Thanks
Its just the same. You can only save as binary.
Ok thankyou.
You can see on following page that the Lite version indeed doesn’t support version control.
https://www.xojo.com/store/index.php
[quote=290233:@Albin Kiland]I’d say it’s basically essential even if you’re a lone developer though
Being able to revert to earlier revisions is priceless![/quote]
TimeMachine?
Without being able to annotate the change and control the granularity of check-in, you lose so much benefit. Don’t get me wrong, automatic backup is better than no backup at all, and manual save-as versioning is useful, but true source code control is just so much better, even as a solo developer.
Ok… somebody correct me if I am wrong here… but isn’t this how a standard VCS system works?
- Initial check-in : Entire source code file(s) are stored in a repository
- Next Check in : VCS system does a DIFF and stores only the “patch” required to tranform original to current versions
- same is done for all remaining check-in/out events
Therefore a CHECKOUT version is the base-version with all the patches applied. to check out a specific “version” is a matter of applying only a selection of the patches. I assume there is ways to commit a new BASE version in the sequence.
This is my understanding, and is actually the reason I avoid VCS at all costs… I had a large project in a VCS system stored on a remote UNIX server (this was years ago), and one day when I checked it out, it was gibberish… and oh yeah… the sys admins had not logged that disk drive into the auto backup system… so I had squat… Lucky for me however, I’m paranoid, and had a complete version stored on my local drive as well…
For a BINARY, I would REALLY not trust a patching process, and then the “value” of a VCS systems becomes less