From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3117 invoked by alias); 9 Dec 2002 17:40:20 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3045 invoked from network); 9 Dec 2002 17:40:19 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 9 Dec 2002 17:40:19 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 18LRt9-0000WZ-00; Mon, 09 Dec 2002 09:40:15 -0800 To: "Joseph S. Myers" Cc: Subject: Re: source mgt. requirements solicitation References: From: Zack Weinberg Date: Mon, 09 Dec 2002 09:42:00 -0000 In-Reply-To: ("Joseph S. Myers"'s message of "Mon, 9 Dec 2002 09:08:35 +0000 (GMT)") Message-ID: <87adjf9jls.fsf@egil.codesourcery.com> User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00453.txt.bz2 "Joseph S. Myers" writes: E> On Sun, 8 Dec 2002, Zack Weinberg wrote: > >> 0a. All data stored in the repository is under an end-to-end >> checksum. All data transmitted over the network is independently >> checksummed (yes, redundant with TCP-layer checksums). CVS does >> no checksumming at all. > > Doesn't SSH? I assume it has to, since cryptography usually requires that. > (And CVS does checksum checkouts/updates: if after applying a diff in cvs > update the file checksum doesn't match, it warns and regets the whole > file, which can indicate something was broken in the latest checkin to the > file (yielding a bogus delta). I didn't know that. But, as you say, it's not nearly enough. (When was the last time we got a block of binary zeroes in a ,v file and nobody noticed for months?) > 0aa. Checksums stored in the repository format for all file > revisions, deltas, log messages etc., with an easy way to verify > them - to detect corruption early.) Worth pointing out that subversion doesn't do as much checksumming as we'd like, either. > The normal current practice here is for branch ChangeLogs to be kept > in a separate file, not the ChangeLogs that need merging from > mainline. (In the case of BIB the branch ChangeLog then goes on the > top of the mainline one (with an overall "merge from BIB" comment) > when the merge back to mainline is done. For branches developing > new features a new ChangeLog entry describing the overall logical > effect of the branch changes, not the details of how that state was > reached, is more appropriate.) Unfortunately, this is not how BIB was done, and I'm stuck with the way it is being done now (the normal ChangeLog files are used, and I resolve the conflict on every merge). Next time around, it would certainly be easier to use a separate file -- but better still to avoid maintaining the files at all. zw