I discovered Junction today, while looking for a way to easily test my Groovy/Hibernate integration on all three major CFML runtimes. It's part of Sysinternals, which is a suite of tools aimed at making Windows not suck so much. It's got all the low-level utilities you need to efficiently manage and monitor your Windows machines that Microsoft figured people would be happy to write and compile some C++ to use.
Junction, as you might guess, is a utility for managing NTFS junction nodes, which are the equivalent of *NIX symlinks. With symlinks, I can have a single working copy "live" inside three different web roots, one for Railo, one for CF, and one for OBD. Any changes made to that working copy are instantly available in all three places without any need to sync anything.
As you can imagine, this makes testing a breeze: just save and go refresh the tab for the runtime in question, and when it's set, go refresh the other tabs to ensure it still works everywhere else. Until this point, I'd always used separate VMs, but that's way overkill for a standalone CFML app. If you've got database and web server integration and all that, VMs are a lifesaver, but I just wanted to run the same 30 files in three web contexts and Junction is perfect.
One big difference as I just discovered is that deleting a junction is not the same as deleting a symlink.
If you delete a symlink in *nix, the files is still at the original location. If you delete a junction created with this tool, you delete the files and the original location shows up empty.
Make sure you delete the junction with this junction tool rather than how you would normally delete a folder or symlink.
Read that info about NTFS junctions behaviour on Win XP before attempting any operations on them (even as simple as moving them on to different volume) – http://en.wikipedia.org/wiki/NTFS_junction_point
Vista finally introduced symbolic links to windows family, and hopefully they will stay there. Didn't yet had the ocasion to try them tho.