Branch generates ImmortalLimbo warning ?

[John Arbash Meinel]

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

Maritza Mendez wrote:
> 
> I am running bzr 2.2 packaged with bzr-explorer for Windows with the
> same "big" project I've described here before.
> 
> I have a shared repo at D:/VCS/bzrEval with main branch
> D:/VCS/bzrEval/trunk and I branch to D:/VCS/bzrEval/dev_d within the
> shared repo and I get the following message in .bzr.log (and in the
> bzr-explorer GUI):
> 
> ImmortalLimbo: Unable to delete transform temporary directory
> D:/VCS/bzrEval/dev_d/.bzr/checkout/limbo.
>     Please examine D:/VCS/bzrEval/dev_d/.bzr/checkout/limbo to see if it
> contains any files you wish to
>     keep, and delete it when you are done.
> 
> [Traceback is attached]
> 
> It turns out that the limbo directory is empty.  But what would I have
> done if it had files in it?  I need to understand this well enough to be
> able to explain it to people who are just trying to get their (non-bzr)
> jobs done.
> 

I have a strong suspicion you have a filesystem race condition, though I
don't know *why*. Specifically, if you run bzr, get this error, and then
look and find the directory empty, I would guess that for a brief moment
after we issued a rename command, it didn't actually take affect before
we issued the 'rmdir' command.

Is 'D:' a mounted directory or is it a local disk? A mounted directory
would be much more likely to experience a race condition.

If you really do have a race, one option internally is to just add a
polling loop around the rmdir. So we try to delete it, get not-empty,
wait a tick or two, then try again.

I don't know if you are comfortable running bzr from source rather than
from the installed copy. If you are, then we can pretty easily work up
some patches that would at least make debugging this easier. (When we
get a rmdir failure, just listdir() the directory, to see what is there.
If *that* comes up empty, then your system is lying to us for some reason.)

Another possibility is some sort of race condition with Virus Scanners.
They may lock a directory while they are looking at newly created
content, and then after we've moved all the content out, they haven't
stopped searching that dir. (as an example.) Though honestly, I would
expect that to cause problems moving files out of the directory, rather
than problems deleting the directory.


And one further option. Switch to using lightweight checkouts and
treeless branches. You'll likely be better served by this in the long
run (since we don't have to recreate the whole tree content, just the
few files which are actually different). But some of it will depend on
your specific needs. (And yes, it doesn't solve the problem if you still
experience the limbo issue on the first checkout.)


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

iEYEARECAAYFAkxq1XgACgkQJdeBCYSNAANT0ACdEhpTHXQVQGndFxjcm0DVIihA
5JkAn2Dx+Ez/G8FhXGj2YqXM/NWaC/+g
=n48+
-----END PGP SIGNATURE-----