Plastic Transparent VCS

Meh... I use darcs, mercurial, bazaar, git, monotone (etc?) for that.

Basically, any SCM worth its salt can detect/track changes. Plastic will just be the only one that requires a filesystem driver to do it. Note that there is FileystemWatcher (.NET on Windows) and INotify (all others) if you wanted to improve on the performance (which in practice isn't an issue).

As the saying goes: "Now you've got two problems".

The implications aren't trivial.

DokanFS is not portable: it works on windows (though it is similar to what Fuse is on Mac/Linux/...).

Plastic will require the working tree to be on a special mountpoint, which is in actual fact not (just) a filesystem: it is more like an auto-journalling database. This will hurt performance. Expect real trouble with shared fileservers, Access Control Lists (add Active Directory). Visual Studio might not perform very well working on such an FS (due to lack of/suboptimal support for memory mapped files, execute permissions; anyone work in an environment where launching executables off a non-local drive is prohibited? Right, every big corporation has that, and the mechanics rely in part on the availability of NTFS alternative streams, which can mark/sign a file as 'safe for execution'). Now, I wouldn't trust that debugging/running on IIS over the DokanFS would be problem free (will it detect changes in Web.config? Will access control be ok, or do we need to run the ASP worker under an administrator account, just so we can make it access our worktree?). I'd expect real trouble with unicode filenames, filesharing, 64 bit Windows 7/Vista support...

Even if the filesystem is really only a proxy to an existing NTFS folder, we're not safe: that would allow concurrent edits directly to the backing filesystem. How would changes get detected when the Plastic 'transparent FS' driver wasn't properly loaded/functioning?

Oh, and if 'renaming'/'moving' _empty_ directories is so important, by all means make stuff explicit in deployment, or consider documenting things. (I spot a rather spicy paradox between the beloved and beraved 'XDiff' (able to detect functions mov across files!) and the apparent need for tracking 'empty folder identity'. Mind you, I concur that XDiff is something of a marvel (though not entirely new) but, if you care for content over location, how would you mourn the loss of directory renames?

I say, this looks like overkill and costs performance. The number one asset that a developer appreciates about his development workstation is swift operation. Only after that come full automation, user-friendliness and varnish.

Cheers,
Seth