Good morning, everyone. Fine day here, hopefully there too.
I remember a discussion on version saves perhaps a year ago. My problem is I tend to write code, save a version, run the code and if it works I keep it, if I have a serious problem I revert back to the previous version. The problem is I am building a library of versions, most of them now of little value. Problem is I can start getting lost in versions with close numbers.
Would anyone be able to reference that discussion, suggest a new discussion or offer some needed advice.
I case I do not respond after a reply, thank you very much for your help.
This is what I do. My version system is Major.Minor.Bug, with the typical, albeit subjective, meanings. Every deployed change gets a new version number, and every significant change is logged in my notes. Every new version represents a bug fix or an improvement, and with more than a dozen apps in daily use by myself, my clients, and their facilities, I’ve rarely had to revert to a previous version, and then only briefly while I find the regression.
I’ve never felt the need for a formal version control system, despite the exhortations of some forum members that one absolutely must go that route. The only thing I miss out on is the ability to search across text source files, but the organizational simplicity of the binary format balances that out.
If you work on a program for months then the number of versions becomes significant. Do you retain all versions or do you delete older versions after a specific number of months. I have a program that may have twenty versions that may go back nearly a year taking up quite a bit of memory.
Are there any “rules” in how long a version or “save” should be retained for coding and/oe legal reasons? I cannot find any info.
I don’t know of any “rules” and I think legality would only be relevant if there are specific contractual obligations to a client.
I tend to keep all deployed versions and delete any undeployed development versions once a deployment is made. When the source folder gets too crowded I move everything more than 3 or 4 deployments old into an “Old” folder to reduce clutter. But in practice I’ve rarely needed anything more than a couple of deployments old for any reason.
If you use shared code (externals) across multiple projects, as I do, it’s critical to make archival backups regularly using Xojo’s “Collect” feature to make all externals internal and capture a snapshot that can’t be corrupted by subsequent changes to externals.
I can’t imagine a developer’s life without a system like Git anymore. It gives me so much peace of mind knowing that I can experiment with anything without even remotely jeopardizing my project, and that I can access my source code at any time, from anywhere in the world, using any device with a modern browser, and even modify it if necessary… priceless.
I also can’t understand why I should burden myself with the work, time, and additional costs of creating my own backup system and strategy.
And when I’m collaborating on code with others, there’s nothing better than a Git repository…
I will just say that almost every one us that now use a version control system like Git, who advocate for it so enthusiastically, started with a “system” similar to what is being described here.
The only downside is the learning curve, and software like SourceTree makes it much easier. I implore you to stop making things harder than they need to be.
I often find it very valuable in meetings, too. For example, when we’re talking about something non-coding-related, but suddenly need to remember how we collect the information provided by a program, I go into the browser and display the program’s part on the projector, and we can marvel together at how brilliant I am (read: I’d like to be…).
I’d like to thank everyone who responded to my question. I appreciate the references and am reading the info on the products suggested. You’ve saved me a great deal of time with your willingness to help me.
2 main advantages to a source control system are that each checkpoint is extremely small. It doesn’t save the entire project, just the bits that changed. Secondly, you can give a brief description of what you did and why you did it. That information becomes invaluable over time as it answers the head scratching question, “what did I do here?”
If you are using GitHub, their own “GitHub Desktop” application allows all the usual operations and doesn’t cost anything. It even supports slightly more advanced operations such as managing branches.
To add to what Tim said, you can also look back at each version and see exactly what changes you made at the time. In terms of your current versions you can integrate them into the GIT system:
Start by opening the oldest version and saving in “XOJO Project” format.
Push that to the server.
Replace the source files with the next version and allow GIT to show you the differences.
Enter any information about the changes into the comments and push that to the server.
Continue until you run out of versions, ending up with your most recent.
You can start new branches/forks and experiment. If you don’t like the new changes, delete the branch/fork. And if you like what you did, migrate them into the main branch. Git will try to automatically resolve conflicts which in almost all cases works like a charm if you work alone. And in most cases also, while you work with many on a branch/fork.
There are many, many more features. But the “let me see what i did back then” and “let me revert my changes” and the “let me download my project onto a new machine and continue where i left” are the most valuable for you (@James_Backus), i think.
I must say, though, it will change the way you code. You start thinking in terms of small discrete functionality and how it fits into the larger project. It actually makes you a better and more methodical coder. I need to implement and test this piece, which will advance the new feature in this way.
Taking a Belt & Suspenders approach - do hourly backups too.
E.g. if you are a mac user, have Time Machine backups running doing hourly backups.
I’ve definitely had a few times when I went “oops” and messed up some large chunk of a project, and it was in between commits to the repository. I could have reverted to my last commit, but that may have been days ago.
Being able to go back one or two hours using Time Machine and recover a known working version is invaluable.
