[MERGE] [BUG 363837] Catch _win32_delete_readonly failure to remove file or directory and try to recover

[Maritza Mendez]

On Wed, May 6, 2009 at 8:52 PM, Martin Pool <mbp at sourcefrog.net> wrote:

>
> I think a requirement to close Visual Studio before doing bzr
> operations is a bug in bzr (and probably also in VS but anyhow.)  We
> could potentially work around that behaviour by having a mode where we
> open and modify the existing files rather than replacing them,
> assuming VS will even let you do that.  (But that's a separate bug, so
> let's handle it separately.)
>

Could be.  But VS does this sort of thing so much that I just accept it.  :(

> 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.

I agree with you too, let's just let them happen.  Thanks.
>

ok!


> There is <http://doc.bazaar-vcs.org/bzr.dev/developers/index.html>
> which is derived from doc/ in the source tree, though at the level of
> individual functions we'd tend to describe their purpose and
> limitations in the docstring.  I'm sure there are many shortcomings in
> those documents, but the best way to improve it is for readers like
> yourself to point out where things are missing or unclear and we'll
> improve it.
>

Thanks.  I will use this as a reference in future.  By the way, the
docstrings are really very good in bzr!

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090506/dfb98a65/attachment.htm