Originally posted by Tim Holloway:
Making the entire project arbitrarily mobile might be a strain. I've never attempted to make the "Project" relocatable, just the project contents. That is, I can team-commit a project to CVS that lives in my local C:\projects directory, go to a Linux box, and check it out under /home/mydir/workspace and expect everything to work OK, but I don't migrate the project around within the machine willy-nilly, and wouldn't really want to. Even if the machine didn't get confused, I almost certainly would.
I know that recent Fedora releases are pretty good about consistently mounting unique devices at the same mountpoint, and while I haven't looked at the details lately (or for USB devices), I do know it was possible to lock down CDROM drive IDs as far back as Windows 4.0.
I understand where you are coming from with this, but unfortunately I still have problems if the configurations of directories used to store project files are not "mobile".
The main problem is that I develop on several different machines. At a minimum my office workstation and my laptop, but also often machines at client sites or at the college where I teach part time. Synchronizing
anything between all these different machines is an unworkable nightmare, so I long ago took to storing
all my changeable data (project settings, source code, etc.) on removable media.
You are right that any particular machine usually mounts the same removable device on the same drive/mountpoint. However, these different machines each mount my USB drive on different drives: My workstation used to use drive F, but now prefers drive G since I added a USB hard drive and upgraded my USB flash drive from 256MB to 1GB. My laptop has a built-in multi-format card reader that grabs drives up to about K, and client/college machines are both different again and usually locked down to prevent changing stuff like that.
I have installed Java and Eclipse on each machine, and can configure each one to use a directory on whatever drive letter the removable media uses on that machine as its project workspace. When I do that it "sees" the projects, but falls over when it tries to access the project files from a (hard-wired) drive stored in the project configuration.
There is no obvious engineering reason that I can find for storing the full, absolute path in such cases, when a path relative to the configured Eclipse project directory would do the job just as well, and also work in my situation.
A subsidiary problem is that I only have remote CVS access from some machines. I do most of my commits of my own projects from my office workstation (which has access to my own local CVS, and to Sourceforge). Often my laptop will have no network connection at all, and college systems typically prevent network access for stuff like this. With work for clients, I usually only have access to their code repositories (whatever bizarre system they may favour) when I am on-site and inside their firewall. So sharing via CVS (or whatever) is also not really feasible.
I just find it really irritating that the Eclipse UI teases me by
showing the hard-wired project directory, but will not let me edit it to change it. Even if I wanted to change it to a relative path from the Eclipse project directory.