Orion, I'll review this change shortly and let you know if I have any feedback.
~Jimmy On May 24, 2011, at 11:51 PM, Orion Edwards <ori...@gallagher.co.nz> wrote: > As mentioned in the bug http://ironruby.codeplex.com/workitem/6118 , > IronRuby .rbproj files have some severe problems when working with > source-controlled projects. > > I discovered that one of the major causes of this was the way that the DLR's > DirectoryBasedProjectNode was handling add/rename/delete operations from the > filesystem. > When it would get one of these notifications, it would immediately > add/remove/rename the file. If the project was bound to source control, this > would pend a correpsonding add/remove/rename change to the source control > provider. > > Unfortunately, some external editors, diff/merge tools, and source control > providers (in particular the Team Foundation Server one) implement "atomic > saves" by writing to a .tmp file, deleting the original file, and then moving > the .tmp file into place. > This causes visual studio to pend an "add" on a .tmp file which doesn't > exist, pend a "rename" on that file, and then pend a "delete" on the original > file. The first two operations seem to get ignored by the TFS source control > provider, but the delete does not. > > This leads to the bizarre circumstance where performing a TFS "get-latest" > operation will pend deletes on any files that have been updated. > > The following commit fixes this issue by implementing a "throttle" mechanism. > - When a file system operation occurs, it queues a "file update" operation > keyed by the file path and kicks an 0.2 second dispatcher timer. > - Subsequent operations push back this timer so it will only fire after 0.2 > seconds of idle time > - When the timer fires, it runs each "file update" operation, but only if it > would still be valid > (eg: an "add" operation will only be run if the file still actually > exists after the 0.2 seconds) > > I have been using this modified code for a week now and while it certainly > doesn't fix all the issues with .rbproj files, it does fix the "pend deletes" > problem, and overall the project is much more stable. It does not seem to > have caused any adverse effects. > > Link: > > https://github.com/gglresearchanddevelopment/ironlanguages-main/commit/674aa76aa7d90b64214003f50e1b01c4c6d02188 > > This e-mail is confidential and may contain information subject to legal > privilege. If you are not the intended recipient please advise us of our > error by return e-mail then delete this e-mail and any attached files. You > may not copy, disclose or use the contents in any way. > > The views expressed in this e-mail may not be those of Gallagher Group Ltd or > subsidiary companies thereof. > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
