Take two at r102841.

Delete all .pyc on update. Stale .pyc can cause weird issues.

Take two at r102841.

Forgot to use $base_dir, so the .pyc files in the checkout were deleted, instead
of the ones in depot_tools. Since some slaves have very large checkouts, they
appeared as hung.

R=cmp@chromium.org
BUG=
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=103056

[cmp, 2011-09-27 21:41:24]

http://codereview.chromium.org/8059001/diff/1/update_depot_tools
File update_depot_tools (right):

http://codereview.chromium.org/8059001/diff/1/update_depot_tools#newcode98
update_depot_tools:98: find $base_dir -iname "*.pyc" -delete
Is this to clean out old pyc files?  Can you update the description and add a
comment to explain that?

$base_dir -> "$base_dir"

I guess the claim here is that the speed benefit of keeping the .pyc files
around at all for even a second run is not worth the possible issues that arise
from having old .pyc files around due to a conflicting change?

[Dirk Pranke, 2011-09-27 22:13:05]

On 2011/09/27 21:41:24, cmp wrote:
> I guess the claim here is that the speed benefit of keeping the .pyc files
> around at all for even a second run is not worth the possible issues that
arise
> from having old .pyc files around due to a conflicting change?

Generating the byte code is very fast; it's definitely not worth keeping
potentially stale .pyc's around for this. In WebKit-land, we delete all of the
.pycs up front as part of the python unit tests for just this reason.

[cmp, 2011-09-27 22:20:51]

lgtm with nits, then

[commit-bot: I haz the power, 2011-09-27 23:59:22]

CQ is trying tha patch. Follow status at
https://chromium-status.appspot.com/cq/maruel@chromium.org/8059001/4002

[commit-bot: I haz the power, 2011-09-28 00:05:18]

Change committed as 103056