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\.plugins\org.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\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.pde.core.prefs is not exported/imported, that the file .settings\org.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:\path\to\tempalte\workspace\.metadata\.plugins\org.eclipse.core.runtime\.settings
set WORKSPACE_SETTINGS_DIR=C:\path\to\actual\workspace\.metadata\.plugins\org.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:\Dropbox\eclipse_workspaces\
set SETTINGS_DIR=.metadata\.plugins\org.eclipse.core.runtime\.settings
REM set SETTINGS_DIR=.metadata\.plugins\org.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
