From owner-freebsd-stable  Wed Mar 26 17:46:46 1997
Return-Path: <owner-stable>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id RAA21757
          for stable-outgoing; Wed, 26 Mar 1997 17:46:46 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21751
          for <stable@FreeBSD.ORG>; Wed, 26 Mar 1997 17:46:42 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id MAA02473; Thu, 27 Mar 1997 12:44:32 +1100
Date: Thu, 27 Mar 1997 12:44:32 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199703270144.MAA02473@godzilla.zeta.org.au>
To: imp@village.org, rkw@dataplex.net
Subject: Re: SUP
Cc: stable@FreeBSD.ORG
Sender: owner-stable@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Hmmm, I've only had to reconstruct trees when I ran out of disk space
>due to a large number of items coming into the tree.  What could I
>have done to prevent that?  That's really the only problem I've had
>with CTM other than an occasional "oops" where things like eBones or
>secure have gone out accidentally...

I've had to edit the CTM updates about 20 times due to them failing
when I ran out of disk space.  (Technique: edit .ctm_status to reduce
the number by 1; then remove items that have already been updated
from the CTM input file; then run ctm and note the md5 mismatch; then
edit the CTM input file to fix the mismatch.)  I think this easier now
using some option to ignore already-updated files.

BTW, ctm -? doesn't give a usage message.

Bruce