From owner-freebsd-current Sun Feb 11 13:30:56 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA26510 for current-outgoing; Sun, 11 Feb 1996 13:30:56 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26491 for ; Sun, 11 Feb 1996 13:30:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18728; Sun, 11 Feb 1996 14:25:40 -0700 From: Terry Lambert Message-Id: <199602112125.OAA18728@phaeton.artisoft.com> Subject: Re: CVS ISSUES To: terry@safetynet.net (Terry Lambert) Date: Sun, 11 Feb 1996 14:25:40 -0700 (MST) Cc: julian@ref.tfs.com, terry@lambert.org, current@FreeBSD.org In-Reply-To: <199602072304.QAA06706@phaeton.artisoft.com> from "Terry Lambert" at Feb 7, 96 04:04:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org Precedence: bulk > > wait for a commit message on the kernel. > > go to your sys checked out tree, > > make some change to the file that the commit was about. > > sup the new CVS tree. (check the new change arrives) > > do a cvs diff > > check what is in the diff > > do a cvs update > > check the file got the new changes > > do a cvs diff > > check the contents again. > > remove the file > > cvs update it again to refetch the unmodified (by you) version > > I will try this diagnostic and let you know. I have successfully updated several files with differening date a version orders. My CVS/SUP interaction problem was either "pilot error" or a result of backing up a version on my CVS tree itself after switching from the primary SUP server to a secondary, and making changes within the switch period. Thanks to Julian and others for their response on SUP/CVS interactions. It's my recommedation that you carfully observe the sync times for a source and destination SUP server if you plan on using a SUP changeover. Because of this, I recommend supping no more frequently than two update periods for a SUP providers local tree. This means that the SUP servers should update no less than three times a day if the SUP dns rotation that was suggested is implemented, assuming a once-daily SUP bu a leaf-node client. Failing that, people using the dns rotation list and getting a random SUP server should update no more frequently than every other day, if they are making any changes to the checked out trees at all. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.