From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Fri, 20 Nov 2009 14:33:00 -0500 Message-ID: <87eintvvo3.fsf@red-bean.com> References: <87bpu1451m.fsf@red-bean.com> <874ozs34c6.fsf@notengoamigos.org> <87k58nyih3.fsf@red-bean.com> <87d4eerm8w.fsf@red-bean.com> <87k4yy7qba.fsf@yahoo.com> <87vdiiof1d.fsf@canonical.com> <87d44ceg5s.fsf@stupidchicken.com> <87bpjwe46n.fsf@red-bean.com> <87zl6vskq0.fsf@red-bean.com> <874op07kb0.fsf@red-bean.com> <87639fr3w7.fsf@red-bean.com> <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <83tywppbxz.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258745610 18623 80.91.229.12 (20 Nov 2009 19:33:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2009 19:33:30 +0000 (UTC) Cc: jearl@notengoamigos.org, ian.clatworthy@canonical.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 20:33:23 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NBZEJ-0001Lh-1z for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2009 20:33:15 +0100 Original-Received: from localhost ([127.0.0.1]:51451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBZEI-0007Q8-5m for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2009 14:33:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBZED-0007Pq-CE for emacs-devel@gnu.org; Fri, 20 Nov 2009 14:33:09 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBZE9-0007P6-UX for emacs-devel@gnu.org; Fri, 20 Nov 2009 14:33:09 -0500 Original-Received: from [199.232.76.173] (port=50318 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBZE9-0007P3-Nt for emacs-devel@gnu.org; Fri, 20 Nov 2009 14:33:05 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:51793) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NBZE7-0002FP-51; Fri, 20 Nov 2009 14:33:03 -0500 Original-Received: from localhost ([127.0.0.1]:60299 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1NBZE5-0002sV-Mk; Fri, 20 Nov 2009 13:33:02 -0600 In-Reply-To: <83tywppbxz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 20 Nov 2009 15:23:20 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:117374 Archived-At: Eli Zaretskii writes: >> * Spot-check a change. [PASS] > > What does it mean to "spot-check a change"? Also, what are the > criteria for judging these "spot-checks", according to which you say > "PASS"? It means I randomly picked a change in CVS and confirmed that the same change exists in Bazaar, with the same data and metadata. > Would it be a good idea to show a few lines? Or are you only > interested in the fact that the "Update from HEAD" log was caught? > How about the list of files -- did you verify that it is identical to > the original one? Nope. In all the other spot-checks I did, I verified every file and directory. But in this one, it was too big to do manually, and I didn't bother to script that it was the _exact_ same set of files. Instead, I just spot-checked the list of files too, from both directions (i.e., spot-check a few from the CVS side to make sure they were in Bzr, and a few from the Bzr side to make sure they were in CVS). Then I moved on to other checks. (After all, in theory, a full and complete automated check of the conversion is equivalent to writing the converter in the first place; anything less is simply deciding where to compromise :-) .) >> These three changes in CVS... >> >> 2002-10-29 04:45 lektu >> * nt/ChangeLog (1.74): >> Added "(tiny change)" marker. >> >> 2002-10-29 04:41 lektu >> * lisp/ChangeLog (EMACS_21_1_RC.237): >> Add "(tiny change)" markers. >> >> 2002-10-29 04:38 lektu >> * lisp/ChangeLog (1.4464): >> Added "(tiny change)" marker. >> >> ...match these *two* changes in Bazaar: >> >> (on the EMACS_21_1_RC branch): >> ------------------------------------------------------------ >> revno: 40805 >> committer: Juanma Barranquero >> timestamp: Tue 2002-10-29 09:41:08 +0000 >> message: >> Add "(tiny change)" markers. >> modified: >> lisp/ChangeLog >> >> (on the trunk branch): >> ------------------------------------------------------------ >> revno: 48050 >> committer: Juanma Barranquero >> timestamp: Tue 2002-10-29 09:45:19 +0000 >> message: >> Added "(tiny change)" marker. >> modified: >> lisp/ChangeLog >> nt/ChangeLog > > So what does it mean -- that the conversion tries to second-guess > filesets based on log entries? Yes. It's not "second-guessing", though, it's "first-guessing", because CVS doesn't record atomic changesets, even though the people committing in CVS intend atomic changesets (i.e., everything committed in a given "cvs commit" command). For all version control systems FOO that support atomic changesets (which is every system written since CVS, and many written before CVS), all CVS->FOO converters must try to rederive the intended changesets from CVS's almost-but-not-quite-good-enough metadata. All the converters use roughly the same method for doing so, but due to various tweaks and options in the algorithm, they sometimes produce different results. Usually those differences are not important in practice. -Karl