BZR deleting files after a pull

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Nickolas wrote:
> Hi,
> 
> I think we've seen this bug a couple of times now but this time we may
> have a bit more information about it.
> 
> I had locally modified files when I did a pull (there were definitely
> changes to be pulled) and got the following output:

v- This looks like bzr got some sort of OS error while trying to update
the working tree. Did you have 'main.cpp' open in an editor? Also, can
you look at:
C:\Documents and Settings\<username>\.bzr.log

Which should show more detailed information about what was going on when
this happened.

> bzr: ERROR: [Errno 22] Invalid argument:
> u'C:/src/trunk/consoleXiClient/main.cpp'
> 

...

> I *think* I have seen exactly the same problem before (with BZR 0.10)
> though last time I didn't notice the:
> bzr: ERROR: [Errno 22] Invalid argument: ...
> But that was probably because last time I didn't even notice that files
> had been deleted till well after I did the pull.

It sounds like it started trying to update the working tree with all of
the changes that you pulled, and marked the tree as needing all of the
new files. Then while it was updating, Windows denied it from doing
something, so it didn't get the chance to create all the new files.

At this point you haven't actually lost anything, but probably your
working changes are difficult to get to. (bzr revert would get your tree
to a pristine state, but that would also get rid of your local changes).

> 
> Additionally:
> - I had no local modifications to the file
> C:/src/trunk/consoleXiClient/main.cpp.
> - Other people had made modifications to that file -- I was hoping to
> pull their changes.
> - I'm not sure if BZR pulls files alphabetically but
> C:/src/trunk/consoleXiClient/main.cpp was probably the first file
> alphabetically in our repo that had changes when I tried to pull.
> 
> Anyway, Bzr version is:
> C:\src\trunk>bzr --version
> Bazaar (bzr) 0.11.0
> 
> And I'm on windows, obviously, though 'devserver' was running linux.
> 
> Has anyone seen anything like this before, or know what might be going on?
> 
> Thanks,
> 
> CYA

My best guess is that we are running afowl of Window's policy that you
can't change files that are currently open. We have a couple things we
could do at this point:

1) Undo any changes that we have made, and change the working tree to
still think it was the old version. This would be 'safe', in the sense
that if it cannot update the working tree, it leaves it the way it was.
It doesn't really give you a good indication about what you can do to
update your tree, though.

2) record that there was an error for a given file, but keep trying to
apply all the rest of the changes until you are done, and then report to
the user all of the things that you couldn't do. This has the nice
property that you don't have to backtrack, and means that we try to
update as much as possible. From there, a user could do 'bzr revert
specific/file' in case there were things that we failed to update.

I don't think anything has actually been lost at this point, just that
the tree is in a sort of intermediate state that is hard for a user to
recover from.

Aaron is the one who has worked the most on updating the working tree.
And I know he has been interested in doing rollback (1), but I'm
thinking (2) might actually be a better solution.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNc+FJdeBCYSNAAMRAmVPAJ46NaExorjHit7Vt6qbh6hR4kq6GQCdGbSy
61ElwcF1WR19538+wjdcy6w=
=/EfL
-----END PGP SIGNATURE-----