Re: Problem reports for version control systems

["Thomas Mueller" <mueller6726%twc.com@localhost>]

> Hi all,
> The problem reports people have in their emails are completely inadequate for
> trying to determine what is going wrong for people trying to access the NetBSD 
> source. 
         
> Since I was the first person to post an inadequate report in this first batch,
> I'll go first at trying to do better. There are three sections to this email.
> First, a description of the host and network I am running this on. Second, a
> description of what I did, what I got, and what I expected to get. Third, I'll
> speculate on possible causes.
         
> Host and Network
> ================
         
> I am in New Zealand, which tends to have good internet access to the home and
> Long Fat Networks (LFNs) to the rest of the world.
         
> The host is a Xeon E3-1241 v3 @ 3.50GHz with eight hyperthreads and 32GB RAM. 
> It has a 128GB SSD for / and 4x4TB disks in a raidz zpool on /vol. All work is
> being done on /vol. The OS is NetBSD 9.99.79.

> The network is a 1Gb/s LAN through to a smaller NetBSD router running NPF with
> MSS clamping enabled so that I can get Netflix. My ISP does not use CGN for my
> IPv4 connection. My IPv6 connection is tunnelled through to Hurricane Electric
> in Sydney, Australia.
        
> Â Â Â  ceph4% cvs -v

> Â Â Â  Concurrent Versions System (CVS) 1.12.13 (client/server)
> Â Â Â  with CVSACL Patch 1.2.5 (cvsacl.sourceforge.net)
         
> Â Â Â  ceph4% hg --version
> Â Â Â  Mercurial Distributed SCM (version 5.3.2)
         
> What I Did, Got, and Expected
> =============================

> In all cases, I pretty much copied instructions from the NetBSD web site.
         
> Â Â Â  ceph4% cd /vol/src/cylc/src-CVS
> Â Â Â  ceph4% export CVSROOT="anoncvs%anoncvs.NetBSD.org@localhost:/cvsroot"
> Â Â Â  ceph4% export CVS_RSH="ssh"
> Â Â Â  ceph4% cvs checkout -A -P src
> Â Â Â  cvs checkout: Updating src
> Â Â Â  U src/BUILDING
> Â Â Â  U src/Makefile
> Â Â Â  U src/Makefile.inc
> Â Â Â  U src/README.md
> Â Â Â  ...
> Â Â Â  U src/crypto/external/bsd/heimdal/dist/lib/wind/test-utf8.c
> Â Â Â  [very long pause here]
> Â Â Â  client_loop: send disconnect: Broken pipe
> Â Â Â  cvs [checkout aborted]: end of file from server (consult above messages if any)

> I expected the output to not pause too much and for the listing to run through
> to the end of src/usr.sbin without disconnecting and aborting.

> Â Â Â  ceph4% hg clone -U https://anonhg.NetBSD.org/src src-hg
> Â Â Â  [lots of progress stuff gets displayed here]
> Â Â Â  applying clone bundle from https://cdn.NetBSD.org/_bundles/src/77d2a2ece3a06d837da45acd0fda80086ab4113c.zstd.hg
         
> Â Â Â  adding changesets 
> Â Â Â  adding manifests
> Â Â Â  adding file changes 
> Â Â Â  added 931876 changesets with 2425841 changes to 439702 files (+417 heads) 
> Â Â Â  finished applying clone bundle
> Â Â Â  searching for changes
> Â Â Â  adding changesets
> Â Â Â  adding manifests
> Â Â Â  adding file changes
> Â Â Â  adding changesets
> Â Â Â  adding manifests
> Â Â Â  adding file changes
> Â Â Â  added 22612 changesets with 161374 changes to 110024 files (+6 heads)
> Â Â Â  new changesets 26c8f37631b6:6f32acf2c5e1 (230 drafts) 
> Â Â Â  280602 local changesets published

> This is what I expected.

> Speculation
> ===========
         
> I'm suspicious of the long pause in the CVS example. Maybe one end or the
> other of the CVS connection spent too long doing disk I/O or calculating stuff
> and then NPF timed-out the connection?

> Cheers, 
> Lloyd

I too get long pauses with cvs, both at the beginning, and even longer at the end after update is complete.

This is equally true whether I update using cvs in NetBSD or cvs (built from FreeBSD ports, not in base system) in FreeBSD.

There was a similar but much shorter delay in FreeBSD when updating by svn, before they switched to git.

So I look forward to a switch from cvs to hg when everything is in good working order.

Switching FreeBSD src, doc and ports trees from svn to git was decidedly nontrivial.

Tom