Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Newcomers » Newcomers » How to save the version of code before every build(Save the versions of the code before every build)
How to save the version of code before every build [message #1806575] Fri, 10 May 2019 14:10 Go to next message
ssk ssk is currently offline ssk sskFriend
Messages: 2
Registered: May 2019
Junior Member
I want to see the way the code is evolving , so would like to log the java file before i click a build.
how to maintain such multiple versionS?
Re: How to save the version of code before every build [message #1806578 is a reply to message #1806575] Fri, 10 May 2019 15:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
The workspace already keeps a local history and you can Compare With -> Local History... There's no way to copy all files and of course generally builds happen automatically when you save...

Ed Merks
Professional Support: https://www.macromodeling.com/
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 Go to previous messageGo to next message
Patrick Moran is currently offline Patrick MoranFriend
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 #1806590 is a reply to message #1806584] Sat, 11 May 2019 04:08 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
If I had this problem, I would keep the projects in a Git repository. I'd either use my Github account for the repository (safe from any potential problems with my computer's hard disk), or I would just create a local bare Git repository and use that (fast and local). Then I would commit my changes when they are in a good state and at that point I could easily compare the current state with the previous state. In fact I would of course have a whole history of all commits/states so that I could easily compare anything with anything and could easily discard any local changes gone astray or merge back in changes that were lost. Of course that's all the entire point of a source code repository with Git being the best available for that purpose and having excellent integration with Eclipse...

Ed Merks
Professional Support: https://www.macromodeling.com/
Re: How to save the version of code before every build [message #1806591 is a reply to message #1806590] Sat, 11 May 2019 06:38 Go to previous messageGo to next message
Patrick Moran is currently offline Patrick MoranFriend
Messages: 141
Registered: March 2018
Senior Member
I'm glad to know about this repository. I sounds like just what I have needed all along. Thanks.
Re: How to save the version of code before every build [message #1806812 is a reply to message #1806591] Wed, 15 May 2019 14:46 Go to previous messageGo to next message
ssk ssk is currently offline ssk sskFriend
Messages: 2
Registered: May 2019
Junior Member
For Git , we have to manually push after each compilation. But How can I auto do at every compilation from eclipse??
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
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/
Previous Topic:Moderated Post
Next Topic:Configuring my IDE to work on Linux
Goto Forum:
  


Current Time: Thu Mar 28 15:16:47 GMT 2024

Powered by FUDForum. Page generated in 0.04536 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top