Sometimes "bzr version-info" doesn't complete

What sort of checkout -
svn co svn://FOO
bzr co svn://FOO
bzr co --lightweight svn://FOO
?

bzr co svn://FOO

On Mon, 2010-05-31 at 13:16 +0000, Jean-Paul Calderone wrote:
> bzr co svn://FOO
Does it work in a standalone branch ("bzr branch svn://FOO" ?)

Cheers,

Jelmer

> Does it work in a standalone branch ("bzr branch svn://FOO" ?)

I'm not sure what you mean. Possibly my bug description was insufficiently clear about the problem.

For a *particular* checkout, 'bzr version-info' sometimes completes and sometimes does not complete. I would not be surprised at all if, in the cases where it does not complete, the cause is that the network has dropped some packets and the TCP connection has silently disappeared. I wouldn't expect 'bzr version-info' to complete successfully in such a case (although if it can, that would be pretty awesome!). However, I would at least like it to finish with an error eventually.

If that was all obvious already and you're still interested in a comparison against the behavior with "bzr branch svn://FOO", I *might* be able to investigate that. But this is all happening as part of an automated build system, and switch the system to use "bzr branch" instead of "bzr checkout" is probably a major undertaking, so I'm not positive I'll be able to.

when this happens, can you check where bzr is hanging exactly? (Ctrl+\ should land you in a pdb shell, I assume you know how to use one of those :-))

This is almost certainly an issue in the Subversion client libraries, but perhaps we can work around it in bzr-svn.

> when this happens, can you check where bzr is hanging exactly? (Ctrl+\ should land you in a pdb shell, I assume you know how to use one of those :-))

Hm. I don't know. This all happens as part of an automated build system, so I can't just go in and hit C-\. Plus, apparently by the nature of the failure, this will only happen when there is a network problem, which would prevent me from replicating it on any of the remote hosts I've seen it occur on so far.

It's possible I can reproduce a similar symptom elsewhere under different circumstances, but who knows if that will be a faithful reproduction of the original problem.

I'm pretty sure this is a bug in the underlying libs