From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16318 invoked by alias); 13 Oct 2011 22:17:40 -0000 Received: (qmail 16311 invoked by uid 22791); 13 Oct 2011 22:17:39 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 22:17:23 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LT000400Z33JB00@a-mtaout20.012.net.il> for gdb@sourceware.org; Fri, 14 Oct 2011 00:14:58 +0200 (IST) Received: from HOME-C4E4A596F7 ([84.229.17.178]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LT0004GVZ4WBY80@a-mtaout20.012.net.il>; Fri, 14 Oct 2011 00:14:58 +0200 (IST) Date: Thu, 13 Oct 2011 22:17:00 -0000 From: Eli Zaretskii Subject: Re: GIT and CVS In-reply-to: <20111013215927.GA13931@host1.jankratochvil.net> To: Jan Kratochvil Cc: joseph@codesourcery.com, pmuldoon@redhat.com, gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83mxd41qu4.fsf@gnu.org> References: <20111013215927.GA13931@host1.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00089.txt.bz2 > Date: Thu, 13 Oct 2011 23:59:28 +0200 > From: Jan Kratochvil > Cc: Phil Muldoon , gdb@sourceware.org > > On Thu, 13 Oct 2011 23:50:33 +0200, Joseph S. Myers wrote: > > Even with local disk, git is much more I/O intensive. I timed looking at > > logs from a glibc checkout on local disk: > > > > $ time git log > /dev/null > > > > real 0m18.324s > > user 0m0.560s > > sys 0m0.304s > > $ time git log >/dev/null > > real 0m0.374s > user 0m0.330s > sys 0m0.041s > > You cannot count the first operation, before ./.git gets cached. The first > read is deficiency of kernel filesystem, pre-read and/or no SSD on your system. These comparisons are meaningless. Logs are meant to be read by humans, so the number of seconds it takes to dump all the log entries to the null device is not an interesting measure of any practical importance. More to the point: ChangeLog files can be generated from a VCS log when a release is tarred. They can also be generated when a developer wants a convenient file to look at with usual tools. So whether or not to keep the ChangeLog files is not the issue. The issue is how to save the committers the need to compose 2 different logs, one for the commit, the other for the ChangeLog. This issue should be resolved by the VCS front end in use, like Emacs or whatever people use. When such solutions exist, it is no longer an important issue whether to keep ChangeLog's in the repo or generate them as needed.