[Monotone-devel] "mtn pull" hangs (was: "mtn clone" hangs)

[William Uther]

On 12/11/2007, at 7:19 PM, Ralf S. Engelschall wrote:

> > It seems that the 'mtn pull' part is freezing. The first thing I  
> > would
> > check is if the commands work individually. Can you execute these
> > three commands:
> >
> > mtn db init --db=local.db
> > mtn pull --db=local.db file:///v/freebsd/web/x/freebsd-snapshot.db
> > FreeBSD.snapshot.src
> > mtn co --db=local.db FreeBSD.snapshot.src y
>
> Ah, got it: "mtn pull" already hangs, too!
>
> | $ mtn db init --db=local.db
> | $ mtn pull --db=local.db file:///v/freebsd/web/snapshot.db  
> FreeBSD.snapshot.src
> | mtn: setting default branch include pattern to  
> 'FreeBSD.snapshot.src'
> | mtn: setting default branch exclude pattern to ''
> | mtn: doing anonymous pull
> | mtn: connecting to file:///v/freebsd/web/snapshot.db
> | mtn: finding items to synchronize:
> | [...no more outputs...]
>
> When repeating this under --debug the last lines of debug output are:
>
> | [...]
> | mtn: noting key 'address@hidden' =  
> '8ad89008af9db804b7cc26045f9c0f4b1e059c7a' to send
> | mtn: ticks: c="certificates"/256, k="keys"/1, r="revisions"/64
> | mtn: ckr
> | mtn: i/o probe with 0 armed
> | mtn: wrote 3 bytes to fd -1 (peer stdio)
> | mtn: i/o probe with 0 armed
> | mtn: read 3 bytes from fd -1 (peer file:///v/freebsd/web/ 
> snapshot.db)
> | mtn: processing 0 byte input buffer from peer 
> file:///v/freebsd/web/snapshot.db
> | mtn: queueing refinement query of epoch node '', level 0
> | mtn: Beginning epoch refinement on client.
> | mtn: wrote 31 bytes to fd -1 (peer file:///v/freebsd/web/ 
> snapshot.db)
> | mtn: read 31 bytes from fd -1 (peer stdio)
> | mtn: processing 0 byte input buffer from peer stdio
> | mtn: processing refine cmd for epoch node at level 0
> | mtn: queueing refinement response of epoch node '', level 0
> | mtn: i/o probe with 0 armed
> | mtn: wrote 51 bytes to fd -1 (peer stdio)
> | mtn: i/o probe with 0 armed
>
> > My guess is that the second command will freeze in the same place as
> > 'clone' did.
>
> Yes, exactly!
>
> > And then I'll ask if you're using Windows...
>
> <grin> No, definitely "NO.
>
> > file:// access
> > to local repositories forks a sub-process to read the file, and that
> > sometimes gets wedged on Windows.  If that is the case, then you've  
> > come
> > across a 'known issue' which, as far as I know, noone is actively  
> > working
> > on.  Try avoiding file:// URLs.

I have no idea why the file:// URL would be failing (other than on  
Windows).  This is tested for in
the unit test "netsync_over_pipes".  What platform are you running  
on?  Is the db you're pulling from local, or on some file server?

Will         :-}