Home » Newcomers » Newcomers » How to save the version of code before every build(Save the versions of the code before every build)
| |
Re: How to save the version of code before every build [message #1806584 is a reply to message #1806578] |
Fri, 10 May 2019 18:06 |
Patrick Moran Messages: 141 Registered: March 2018 |
Senior Member |
|
|
I started Java programming with Eclipse because I found a tutorial on Java that offered a very good way for me to make some "teaching machine" software that people all over the world could easily adapt. Unfortunately, it had one problem in it that caused it not to compile unless one line were commented out, and the line commented out seemed trivial. An Eclipse user named Reams brought this problem up. As I built upon the original code I discovered that some addition I had made could cause everything to explode when you tried to run it. Not only would I lose the present version, I would often find that ancestor programs in the same work space would also be corrupted. Somebody, maybe it was Ed Merks, told me about special delimiters that would prevent WindowBuilder from trying to work out the consequences of code that had a dynamic component, e.g., user input of a date would affect the date to be displayed on screen in another text box. I could at least get the design right without things blowing up after I learned to "hide" that part of the code. Going into the design panel of Window Builder would no longer cause Eclipse to hang up and have to be terminated.
Not only could things fail because of that dynamic factor having consequences during or after compilation, but often I would make what I thought were three or four trivial changes, and then the program wouldn't work at all, but going back and trying to remember what I had changed (for one thing because I sometimes forgot to comment the changes), I could spend hours comparing print-outs of what. used to work with what had become toxic waste.
I evolved a simple plan. It takes up some HD space, but I've never used more than half of the available HD memory on any of my Macs.
Every time I got an improvement that I don't want to lose, I just copy that entire project within Eclipse/Package Explorer, e.g. I splat-C on Dogfight03, and immediately do a splat-V to save it to the same column under Page Explorer. Eclipse will suggest naming the new project as Dogfight04, I approve that. When I get around ten projects in "Workspace2019-3-v01" I'll go into my computer system, find the folder for that workspace, do a splat-D to duplicate the folder, change the name to "Workspace2019-3-v02", go back into Eclipse, to file/Switch Workspace, and find the new workspace, v02. When I open it, everything is still there, but now I delete (big red X) all but Dogfight10, which I know is good, and immediately make a Dogfight11, which I can experiment upon without fear that my first ten partial successes will survive. (I know this sounds overly complicated, but there are hidden folders in every workspace, and it is difficult to maintain them when making changes. It is also much safer to delete something, e.g., somebody else's JAR that you're including in your build path, in Eclipse than to go through your computer's file system and delete it there. You do not want to learn why via direct personal experience.)
When I have a breakthrough, I'll save that project to some other workspace, e.g. "Successes," and I'll then lock that file/project.
Once recently something drastic happened. Its effects were incorporated "backwards in time" as it appeared so that all the projects in that workspace suffered the same corruption. Never mind, I thought, I'll just go into time machine and get a good copy there. But not only had TimeMachine copied the latest version of the now-deadly workspace, but even by going back to the earliest version of that folder, maybe a couple weeks ago, the rot had set in there too. I would have thought it impossible, but that is what had happened. Fortunately, if that was called folder 20 then folder 19 still had a good copy of its last version. I just deleted folder 20, and re-duplicated folder 19 and changed its name as I had done before.
Aside from Eclipse issues, except to offer some corroboration for what I just reported, I once had some crucial information relating to a stalker entered into my calendar app. One day I went looking for something and found that all of those calendar events, and only the stalking related calendar events, had been expunged. I was pretty upset about what appeared to be outsider(s) editing my evidence away. But it seems that I had copied out those individual calendar events and put them into a word-processor (Pages) file to work on the sequence where I could write up what I thought was going on. Then, for whatever reason, I deleted that Pages file. The computer system in its wisdom regarded the copied information and the original information as the same information and accordingly removed it not only from the StrangeEvents.pages file but also from my calendar. Some tech at Apple told me that had happened to him, otherwise I'd still be paranoid.
It really pays to keep good backups and to copy really crucial stuff onto another HD that you ordinarily leave disconnected.
Saving before every build is overkill, but saving for every increment of real improvement is a very cost worthy plan of action.
|
|
| | | |
Re: How to save the version of code before every build [message #1806835 is a reply to message #1806812] |
Thu, 16 May 2019 03:24 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
You cannot. But as I already mentioned, there is local history maintained. So on any file, you can use the context menu to do Compare With -> Local History... and there will be every a history of all saved changed of that file so that you can see how it has evolved. A commit should be done when you are relatively happy with the current state because it's working well and now you want to proceed with developing the next "feature" for the software and want to be able to easily roll back or see what you've all changed since the last checkpoint.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Mar 28 15:16:47 GMT 2024
Powered by FUDForum. Page generated in 0.04536 seconds
|