Issue 115: 'mtn pull' over network fails to bring over certs or revision

Reported by Jeff Rizzo, Nov 29, 2010

Steps to reproduce the problem:
-------------------------------

1. create new db with 0.48 on macos, commit one revision on one 
branch
2. mtn serve on macos with the new db
3. try to pull that revision on NetBSD/amd64 with 0.99.1


Expected result:
----------------

certs and revision pulled into new db on NetBSD system


Actual results:
---------------

Successful connection/handshake/etc, 0/0 certs pulled.

I was not able to get this working, so what I did for workaround 
was:

1) scp database to machine with 0.99.1
2) mtn db migrate the db
3) mtn -d :db.mtn pull file:///path/to/db?branch-name

...which worked as expected.

Output of `mtn version --full`:
-------------------------------
netbsd6:riz  /usr/src> mtn version --full                         
             monotone 0.99.1 (base revision: 
8973482283db7c36780dce2b54721ccc0f5b7388)
Running on          : NetBSD 5.99.40 NetBSD 5.99.40 (GENERIC) #1: 
Sat Nov 27 16:16:54 PST 2010  
riz@hack.lan:/Users/riz/Documents/code/netbsd/obj/sys/arch/amd64/comp
ile/GENERIC amd64
C++ compiler        : Unknown ISO C++ Compiler
C++ standard library: Unknown ISO standard library
Boost version       : 1_44
SQLite version      : 3.7.3 (compiled against 3.7.3)
Lua version         : Lua 5.1
PCRE version        : 8.10 2010-06-25 (compiled against 8.10)
Botan version       : 1.8.7 (compiled against 1.8.7)
Changes since base revision:
format_version "1"

new_manifest [c1270158b7fa91abf8235ad129b0476943bde1ed]

old_revision [8973482283db7c36780dce2b54721ccc0f5b7388]

  Generated from data cached in the distribution;
  further changes may have been made.



hack:riz  ~/Documents/code/freebsd/head/sbin/growfs> mtn version 
--full
monotone 0.48 (base revision: 
844268c137aaa783aa800a9c16ae61edda80ecea)
Running on          : Darwin 10.4.0 Darwin Kernel Version 10.4.0: 
Fri Apr 23 18:27:12 PDT 2010; root:xnu-1504.7.4~1/RELEASE_X86_64 
x86_64
C++ compiler        : GNU C++ version 4.0.1 (Apple Inc. build 5493)
C++ standard library: GNU libstdc++ version 20050421
Boost version       : 1_40
SQLite version      : 3.6.11 (compiled against 3.6.11)
Lua version         : Lua 5.1
PCRE version        : 7.8 2008-09-05 (compiled against 7.8)
Botan version       : 1.8.1 (compiled against 1.8.1)
Changes since base revision:
format_version "1"

new_manifest [86bede3ba4251594f3a0f7e0c31560f9f8ce3744]

old_revision [844268c137aaa783aa800a9c16ae61edda80ecea]


I've also attached a typescript of the attempted pull with -v set.

monotone - 26.07 kB

Comment 1 by Francis Russell, Dec 3, 2010

I too have noticed strange issues with syncs between 0.99 and 0.48 
and the two seeming to have differing opinions on what to sync. I'm 
mentioning it here as it seems to be related. 

In particular, when using 0.48 with the new upstream repository, 
I've had it pull ~25 revs and ~6800 certs and had none hit the 
database.

Also, when syncing one of my own projects, I've mtn report nothing 
was synced, yet seemingly have managed to transfer new certs.

I was wondering if you could double check that nothing was synced 
rather than monotone simply saying it wasn't?

Comment 2 by Jeff Rizzo, Dec 3, 2010

Not sure how to check this more than this:  the db I was 
transferring to was empty (I had just created it) and after the sync 
attempt still had no revisions. I just now opened the db with 
sqlite3, and the 'revisions' and 'revision_certs' tables were empty.

Comment 3 by Thomas Keller, Dec 28, 2010

Labels: Milestone:1.0

Comment 4 by Richard Levitte, Mar 20, 2011

Not sure what to say about this...  looking at the typescript, 
absolutely nothing is transfered, because the two ends seem to agree 
there's nothing to transfer...

It would have been nice to see a similar transcript for the server 
end.

Question: if the same server-side database is used with monotone 
0.48 as server on a different platform, do you still have the same 
problem? (could it be a mac port issue)

Comment 5 by Jeff Rizzo, Mar 20, 2011

I can no longer duplicate this issue.  I'm really not sure what the 
problem was, but I'm performing the same steps and actually getting 
the revision across this time.  (Same database, same server binary, 
possibly different 0.99.1 client binary)

I suppose this can be closed.  Sorry for the noise.

Comment 6 by Richard Levitte, Mar 20, 2011

Ok, closing this one.

Status: WontFix
Owner: levitte