Orion Edwards
2011-May-25 03:51 UTC
[Ironruby-core] Codeplex workitem 6118: Requesting Code Review
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.
###########################################################################
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20110525/0aab1fed/attachment.html>
Jimmy Schementi
2011-May-25 13:23 UTC
[Ironruby-core] Codeplex workitem 6118: Requesting Code Review
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 <OrionE at 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 at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110525/db37a243/attachment-0001.html>