<div class="gmail_quote">On Tue, May 5, 2009 at 3:24 PM, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I would make this very specific to windows + diff handling, rather than do it for all files we want to delete. I suppose 1&2 aren't terrible for generic, but I think we'll often have things open that won't be released, like Visual Studio editing. </blockquote><div> This is a very important point. Although Visual Studio is not part of my motivation, I can attest that VS keeps several kinds of files open/locked. Standard advice for my teams is "Close VS before attempting any version control." This is true for all version control systems, not just bzr of course. So it is probably not reasonable for users to expect bzr to deal gracefully with Visual Studio unless integrated version control is a stated goal of the bzr project. On the other hand, external diff support is built into bzr and therefore is expetced to be tolerant of some platform oddness. I see two general threads in this discussion. One thread seems to say that bzr could actively diagnose and compensate for the root causes and that this should be limited to the win32 layer. That was my original opinion, although my solution was not the best. The other thread holds that platform-specific stale temp files (and directories) are ok, especially if the intended operation works and a friendly message is printed instead of an uncaught exception. I am now of this latter opinion and my patch will be along those lines, probably this weekend when I get some time to test. Thanks! -M </div></div>