tag:blogger.com,1999:blog-27232680.post7311421585125703088..comments2024-03-20T06:54:32.435+01:00Comments on Plastic SCM blog: The history/story behind transparent scmF3RD3Fhttp://www.blogger.com/profile/11524626976811746062noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-27232680.post-70117552987912893862014-02-03T22:11:01.180+01:002014-02-03T22:11:01.180+01:00Thanks for this response. Sadly I noticed really l...Thanks for this response. Sadly I noticed really late (because I think it took /forever/ for the comment to be moderated?)<br /><br />Anyways. Solid arguments. Yeah, I had been misreading things a bit.Amberhttps://www.blogger.com/profile/02588145544781882509noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-32650384427335500372012-01-10T17:33:36.057+01:002012-01-10T17:33:36.057+01:00Hi Seth,
Thanks for the comments!
A few remarks:...Hi Seth,<br /><br />Thanks for the comments!<br /><br />A few remarks:<br /><br />1- The "fs stuff" is not there now. It is just a prototype. We're able to "track moves" without the help of a FS driver, of course!!!!<br /><br />2- Well, the "glassfs" will be some sort of "dynamic view", and believe me when I tell you there are huge teams out there under really high demanding environments... demanding it.<br /><br />Regarding your comments:<br /><br />> Basically, any SCM worth its<br />> salt can detect/track changes.<br /><br />You now that Git and Hg can't detect directory moves, don't you? As easy as it sounds, you move a directory with 1000 files and the poor boys detect 1000 file moves... Sad, but true. Try it with Plastic :)<br /><br />> Plastic will just be the only<br />> one that requires a filesystem<br />> driver to do it.<br /><br />As I said, you're missing part of the picture there. We don't need it to detect changes, I'm just talking about a new potential feature.<br /><br />> Note that there is FileystemWatcher (.NET on Windows)<br /><br />I wonder why you think I didn't go through it :). FSWatcher can't detect file "moves". INotify can, but Windows CAN'T (not even the C native interface, it simply doesn't do it). File moves is the missing piece.<br /><br />Also the "watcher" is not meant for precise monitoring, you can loose changes under heavy IO load, which is basically what happens during SCM operation... <br /><br />Thanks for the remarks,<br /><br />pabloPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-65415702311055973322012-01-10T15:18:36.186+01:002012-01-10T15:18:36.186+01:00Meh... I use darcs, mercurial, bazaar, git, monoto...Meh... I use darcs, mercurial, bazaar, git, monotone (etc?) for that.<br /><br />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).<br /><br />As the saying goes: "Now you've got two problems". <br /><br />The implications aren't trivial. <br /><br />DokanFS is not portable: it works on windows (though it is similar to what Fuse is on Mac/Linux/...).<br /><br />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... <br /><br />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?<br /><br />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?<br /><br />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.<br /><br />Cheers,<br />SethAmberhttps://www.blogger.com/profile/02588145544781882509noreply@blogger.com