|.metadata vs Workspace syncing [message #1830885]
||Wed, 05 August 2020 22:45
| John Sellers
Registered: August 2020
USE SCENARIO IN A WORKSPACE|
I tentatively am assuming that it is critical that .metadata state should be in sync with the Eclipse Platform and Projects state and they they should always have the same timeline.
(e.g. these should be backed up and restored together, and if virtualized should be committed or discarded together.)
And I am tentatively assuming that the work content of my workspace is independent enough of the .metadata directory and the Eclipse Platform and Project updates state that I can make my work content persistent in the Cloud while discarding the changes in the VIRTUAL state of the .metadata, Eclipse Platform, and its Projects at the end of a work session.
Generally I would try to commit a session rather than to discard it if there were significant updates or added projects during a working session.
MY QUESTION IS:
Will this scenario tend to work good with Eclipse?
(Please! All comments are welcome!)
[Updated on: Thu, 06 August 2020 02:50]
Report message to a moderator
|Re: .metadata vs Workspace syncing [message #1830889 is a reply to message #1830885]
||Thu, 06 August 2020 03:54
| Ed Merks
Registered: July 2009
The .metadata folder's content is generally a hodgepodge collection of information for many purposes. It certainly includes information about which projects are in the workspace and their physical locations. But also preferences, dialog settings, and other information about the state of the workbench. New versions of the platform may store new types of information or store information new formats that may not be backward compatible with older versions of the platform so typically you get a warning when opening an older workspace with a newer platform because it may not be possible to use that workspace with an older platform. A backup/restore mechanism of course generally should keep timelines in mind...|
In terms of persisting the state of the workspace projects, you'd really be best off to use something like Git for that purpose and install EGit to use it effectively within the IDE. This is the modern professional way to maintain project state and project history with the ability to got back to any point in time (in the Git commit history).
In terms of setting up development IDEs and populating the workspace with projects, that can be fully automated with Oomph:
Here's a large complex example of that in action:
With this approach you can fully automate the creation of an IDE that contains everything you need/want in your development environment (and only those things), as well as all the projects that are in the workspace and any other preferences for that workspace. This way the only thing you need to back up is the *.setup and the projects themselves in a Git repository. Everything else can be replicated/reproduced on any machine by any person anywhere. This makes it clear that installations and workspaces are not precious things to be carefully backed up but rather are transient artifacts that can be discarded and recreated.
Professional Support: https://www.macromodeling.com/
Powered by FUDForum
. Page generated in 0.01680 seconds