Comment 6 for bug 67699

Removing the read-only attribute before bzr operates does help in this case. But if you forget to do this, then bzr will leave your working copy potentially in an unconsistent (or at least difficult to rolling back) state. This behaviour is not what one one expects of a version control system.

bzr should handle such conditions more cracefully. I've listed below three alternatives how to do this; but in the context of this bug, variant b) is assumably be the apropriate one.

a) warning, before anything will be performed, or
b) atomic/transactional operation: if "pull" fails, everything will be rolled back (including restoring your uncommitted changes), or
c) treat permission flag changes as any other file content changes

-----

The following Windows batch script can be used to reproduce the behaviour:

bzr init b1
echo a > b1\a
bzr add b1
bzr ci -m . b1

bzr branch b1 b2
echo b > b2\a
bzr ci -m . b2

attrib +r b1\a

cd b1
bzr pull ..\b2
cd ..

-----

Resulting output:

bzr: ERROR: [Error 13] Access is denied: u'C:/TEMP/t1/b1/.bzr/checkout/limbo/new-1'
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/checkout/>) was not explicitly unlocked
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/branch/>) was not explicitly unlocked
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/repository/>) was not explicitly unlocked