Single common root path for team development with Linux, Windows and Eclipse

For a long time I've adopted the philosophy of having a single, global, path root for all development that is consistent across the whole software team's machines. On Windows I've used SUBST to create a virtual drive letter (eg. R: for 'Repository). I point R to the root of the local working copy of the repositiory I'm currently using. If I have 2 working copies (eg. the trunk and my current branch) then I'll update R: to my current one.

This means that in configuration files eg. for my editor or IDE, they always get the correct files even when I've switched branches. If the whole team does it, we can even share configuration files, build scripts etc via the repository and they will work, regardless of where the current working copy on each machine is actually located.

Well now I'm using Adobe Flex Builder 3 Beta 2 on Linux, which is based on Eclipse.

For Linux I've arrived at the following as my best practice :

ln -s /path/to/working_copy /mnt/root_name

I'm actually running Linux in a virtual machine, and my working copy is shared in via VMWare's shared folders. On Windows I use drive V: via SUBST, and so my main link for general repository use under Linux is now /mnt/v/.

Thats all fine, but not under Eclipse. Using /mnt/v under Eclipse works fine, but in the .project file it expands the symbolic link to something long and ugly which won't mach other developers machines. Damn!

Thankfully there is a simple solution. In Eclipse go to the menu Window->Preferences/General/Workspace/Linked Resources.

Here you can add variables for use elsewhere in the workspace. The DOCUMENTS variable should already be defined here.
So click "New..." and then enter :
Name: V (I'm using capitals to follow the existing convention)
Location: /mnt/v
and click OK and OK again.
Now go to "Project->Properties/Flex Build Path" and for any source folders change them to something like "${V}/this/that/etc". If you add new folders by navigating to /mnt/v first, they will automatically get the ${V} treatment.

Also note that in .project you will get :

<link>
  <name>[source path] etc</name>
  <type>2</type>
  <locationURI>V/this/that/etc</locationURI>
</link>

instead of :

<link>
  <name>[source path] etc</name>
  <type>2</type>
  <location>/mnt/hgfs/something/this/that/etc</location>
</link>

(Note the lack of curly brackets in the first example)

This .project can now be version controlled and used team-wide. However I think the V variable definition will have to be done per machine. Of course, the /mnt/v will have to be done per machine, but that should be maintaned by each developer anyway.