[MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recover
martitzam at gmail.com
Wed May 6 09:46:50 BST 2009
On Tue, May 5, 2009 at 3:24 PM, John Arbash Meinel
<john at arbash-meinel.com>wrote:
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bazaar