'bzr serve --port localhost:0' fails to allocate a dynamic port

Which OS/bzr version are you using ?

Almost all our tests use '0' to ask the system to assign a free port number. It's pretty weird that you get such an error here.

Do you use IPV6 ? (I can't remember if you can easily disable it on OSX).
The bug is propably pretty shallow but needs to be either diagnosed on your host or reproduced somewhere else.

Also, a traceback will help.

An additional note: why do you want to use 0 here ? It makes it harder for the clients to connect to it since they should find the port first...

On Thu, Oct 21, 2010 at 6:34 AM, Vincent Ladeuil
<email address hidden> wrote:
> An additional note: why do you want to use 0 here ? It makes it harder
> for the clients to connect to it since they should find the port
> first...

I don't. :-) I decided to investigate why the test was failing,
discovered that's the reason. 'bzr serve -h' says it dynamically
allocates a port, and it doesn't (at least on Mac OS X). Hence the
bug. I've got no practical purpose for such a feature. :-) I filed
two bugs so we can track the issues separately (should the test be
fixed independent of supporting 0 as a port number, etc).

HTH!

-John

We use 0 so that we don't clash with any other services that might be running.

'bzr serve' prints out what port it is running on, so we spawn it, read what port to talk to it, and go on with our lives.

Other methods of doing this are, allocate a socket but don't actually listen to it. Then you know it is available and force it on the child process.