Alright, what I did (eclipse juno on windows 7) was :
Created a new eclipse workspace, say test
, run it and just shut it down
Made it into a git repo
Committed the files that were created by eclipse along with this .gitignore :
# binary files
*.dat
*.tree
*.index
.metadata/.plugins/org.eclipse.jdt.core/invalidArchivesCache
.metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache
.metadata/.mylyn/repositories.xml.zip
*.resources
# logs
*.log
.metadata/.lock
# later additions
.metadata/.plugins/org.eclipse.pde.core/.cache/
*.running
Switched to a new branch
Fired up one of my workspaces, exported ALL the settings then fired up the test
workspace and imported them. Compared the .metadata/ dirs of the workspaces with the help of Beyond Compare. The .metadata.pluginsorg.eclipse.core.runtime.settings
folders were identical apart from the org.eclipse.ui.workbench.prefs
file - but the differences did not seem important (i.e. workspace specific). On shutting down the workspace the file org.eclipse.jdt.launching.prefs
was also modified. Switched to master and repeated for the rest of my workspaces.
There were complications - so for instance :
the file org.eclipse.jdt.core.prefs
was present in the test
workspace while in the original workspace (from were I imported) there was the (binary identical) org.eclipse.jdt.core.prefs.bak
.
The file org.eclipse.pde.core.prefs
was not imported
The files org.eclipse.jdt.launching.prefs
and org.eclipse.ui.workbench.prefs
differ.
After the fifth workspace I was settled that the files
.metadata/.plugins/org.eclipse.jdt.launching/libraryInfos.xml
.metadata/.plugins/org.eclipse.jdt.launching/.install.xml
are created when settings are imported (in a new workspace), that the file .metadata.pluginsorg.eclipse.core.runtime.settingsorg.eclipse.pde.core.prefs
is not exported/imported, that the file .settingsorg.eclipse.ui.workbench.prefs
is merged on import (namely the *ENABLED_DECORATORS* var stays as is) and the org.eclipse.jdt.launching.prefs
is edited on shutting eclipse down.
There are further complications like files containing project references :
For instance, the file org.eclipse.wst.sse.core.prefs
contains project names from the workspace - I reported this as a bug (it was fixed really quick !).
CDT creates a bunch of files like :
.settings/org.eclipse.cdt.core.prj-<projectName>.prefs
.settings/org.eclipse.cdt.ui.prj-<projectName>.prefs
which are blindly synced on export/import. This actually is a much more complicated case than the previous one - reported it also.
In fact, whatever you have in the .settings
dir will be copied along (I guess as long as it has a .prefs
suffix). This warrants another bug report.
Similar situations are encountered in other files which contain workspace specific options - like in org.eclipse.ui.ide.prefs
which contains references to the working sets - which are rather workspace specific - or in org.eclipse.ui.browser.prefs
which contains the internalWebBrowserHistory - which is usually also workspace specific.
Anyway I decided to go for the hard links - so I normalized my preferences (it would be much much easier to start with a fresh workspace) and copied all the settings apart from org.eclipse.wst.sse.core.prefs
, the cdt
ones and the org.eclipse.pde.core.prefs
(as for some reason it was not imported. The org.eclipse.ui.workbench.prefs
which is rather special contains also the shortcuts). Then I run :
REM move_settings.bat
set SETTINGS_DIR=C:pathoempalteworkspace.metadata.pluginsorg.eclipse.core.runtime.settings
set WORKSPACE_SETTINGS_DIR=C:pathoactualworkspace.metadata.pluginsorg.eclipse.core.runtime.settings
mkdir %WORKSPACE_SETTINGS_DIR%zBackups
pause
FOR /F %%G IN ('DIR^ %%SETTINGS_DIR%%^ /b') DO (
move %WORKSPACE_SETTINGS_DIR%\%%G %WORKSPACE_SETTINGS_DIR%zBackups
mklink /H %WORKSPACE_SETTINGS_DIR%\%%G %SETTINGS_DIR%\%%G
)
pause
for my workspaces.
And guess what : eclipse breaks hard links. I tried soft links (mklink %WORKSPACE_SETTINGS_DIR%\%%G %SETTINGS_DIR%\%%G
) but no joy either.
Finally
I had to hard link (junction) the whole settings dir (along with all the problematic files I mentioned) - this is really not a solution. One of these days the situation must be addressed. Anyway here's the .bat
I used :
:: Change to the directory that this batch file is in
:: NB: it must be invoked with a full path!
:: run the bat from the dir you want to backup your prefs to
for /f %%i in ("%0") do set curpath=%%~dpi
cd /d %curpath%
set WORKSPACES=javaEE javaSE c++ python android
set TEMPLATE_WORKSPACE=name_of_the_template_workspace
set WORKSPACES_DIR=C:Dropboxeclipse_workspaces
set SETTINGS_DIR=.metadata.pluginsorg.eclipse.core.runtime.settings
REM set SETTINGS_DIR=.metadata.pluginsorg.eclipse.core.runtime.settings WONT DO
set TEMPLATE_SETTINGS_DIR=%WORKSPACES_DIR%%TEMPLATE_WORKSPACE%%SETTINGS_DIR%
for %%G in (%WORKSPACES%) do (call :subroutine_needed %%G)
GOTO :eof
:subroutine_needed
set WORKSPACE=%1
set WORKSPACE_SETTINGS_DIR=%WORKSPACES_DIR%%WORKSPACE%%SETTINGS_DIR%
set BACKUP_DIR=%CD%zBackups\%WORKSPACE%
mkdir %BACKUP_DIR%
pause
move %WORKSPACE_SETTINGS_DIR% %BACKUP_DIR%
pause
junction %WORKSPACE_SETTINGS_DIR% %TEMPLATE_SETTINGS_DIR%
pause
I'll update this post as needed