From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Re: Goals for repo conversion day Date: Sat, 25 Jan 2014 11:01:24 -0500 Organization: Eric Conspiracy Secret Labs Message-ID: <20140125160124.GA8171@thyrsus.com> References: <20140124162937.8699D38155C@snark.thyrsus.com> <87r47xs552.fsf@igel.home> <20140124170751.GA23376@thyrsus.com> <87mwils3b3.fsf@igel.home> <20140124185429.GA25191@thyrsus.com> <83k3dpcbpe.fsf@gnu.org> <20140125062551.GA2554@thyrsus.com> <83bnz0cxp8.fsf@gnu.org> <20140125140637.GA5631@thyrsus.com> <83vbx8azss.fsf@gnu.org> Reply-To: esr@thyrsus.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1390665724 11814 80.91.229.3 (25 Jan 2014 16:02:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 16:02:04 +0000 (UTC) Cc: schwab@linux-m68k.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 25 17:02:12 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W75gR-0004OQ-4n for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 17:02:11 +0100 Original-Received: from localhost ([::1]:51673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W75gQ-0000e2-8v for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 11:02:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W75gJ-0000dv-V1 for emacs-devel@gnu.org; Sat, 25 Jan 2014 11:02:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W75gF-00084V-Vn for emacs-devel@gnu.org; Sat, 25 Jan 2014 11:02:03 -0500 Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:41457 helo=snark.thyrsus.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W75gB-000840-8z; Sat, 25 Jan 2014 11:01:55 -0500 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 67DB738041F; Sat, 25 Jan 2014 11:01:24 -0500 (EST) Content-Disposition: inline In-Reply-To: <83vbx8azss.fsf@gnu.org> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 71.162.243.5 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169061 Archived-At: Eli Zaretskii : > > Date: Sat, 25 Jan 2014 09:06:38 -0500 > > From: "Eric S. Raymond" > > Cc: schwab@linux-m68k.org, emacs-devel@gnu.org > > > > 1. Unlifted Bazaar and CVS commit references. > > A mapping file would be more than appropriate for that. The number of > references is below 200, which is small. This was suggested already, > and I don't think anyone objected vociferously enough for us to > consider that as a non-option. *I* object to this. On the grounds that I've been through this dance many times before, and know that such out-of-band representations generally cost more hassle and deliver less than people expect when they think them up. > And, btw, I'm still not sure you have uncovered all of those > references, since the numbers you posted were significantly smaller > than what I get using simple bzr commands. So it could be that you > will be investing a non-trivial effort to do a partial job. I'm not yet certain I have all the CVS references, but I'm pretty sure I have all the Bazaar ones now. Your last feedback led me to improve my search scripts. I'll do another pass before I'm finished. > > 2. CVS commit cliques that should have been coalesced but were not, > > probably because the time window was defaulted too small when parsecvs > > was run. (Very often these seem to be a pairs of a change and its > > ChangeLog description with an empty comment.) > > I'd say leave that alone. When Emacs used CVS, it was customary to > commit each file as a separate CVS command (RMS actually asked for > that), and moreover, have the ChangeLog be committed once for several > unrelated changes in the same directory. So you will be unable to fix > this without a lot of manual work, and for what? we've been living > with this in bzr for several years, with no one complaining. Much less manual work than you think. Reposurgeon was designed with this kind of fixup in mind. While it does take some human judgment to apply the tool properly, the process does not involve grovelling through every commit by hand. It's a tolerable amount of effort even for a repository this large - and if it weren't, I'd add capability to reposurgeon until it became so. As for nobody complaining...this is because your standards are low, and your standards are low because the tools historically used for these conversions were mostly shoddy and badly designed. Windows users don't complain about Notepad, either, because they don't know any better - but that doesn't make Emacs a waste of time. > > 3. Multiple roots. Two of the multiples are emacs and elpa, but others > > are junk lost+found branches which should be carefully inspected and > > then (probably) removed. > > Leave them alone, they don't bother anyone. Removal can be deferred > for later, if we ever feel it to be necessary. See "low standards", above. > > 4. Obsolete tags (very minor problem, unlike the previous three easily > > fixed in git itself, but I might as well do it while larger cleanups > > are in progress). > > Since this is minor, it isn't not worth the trouble, IMO. By itself, no, it wouldn't be. > > 5. Unconverted .bzrignores (and possibly .cvsignores) in the history. > > Why is that a problem? See "seamless history browsing". > > Andreas is not to blame for these problems; the tools available to him > > were deficient in a number of respects (I had not yet written reposurgeon at > > the time of the move to Bazaar). These are all normal issues > > which I've seen before in over a dozen large conversions. > > The repository converted by Andreas has one significant advantage: it > is being actively used for many months. Personally, I trust that more > than any fancy new conversions, especially if we have to switch to git > without a prolonged interregnum, during which both bzr and git are > used (which is probably highly undesirable, if even possible). You appear to have forgotten some important aspects of the plan I posted. Andreas's work isn't going to be thrown away, and there isn't going to be any lengthy interregnum. The way this is working is that I am building a reposurgeon script that expresses a sequence of edits to Andreas's mirror. On conversion day we will apply that script once, after which everyone can re-clone and go on as before. > Noble goals all of them, but I'm skeptical as to whether they can be > achieved in practice. What's worse, we won't know whether some issues > remained until much later. I know they can be achieved in practice because I have achieved them before, many times. Most recently in the conversion of the groff history, but you could check with the maintainers of NUT or Hercules or robotfindskitten or Roundup as well. Or the Blender Foundation - blender is a big reposurgeon conversion done by someone else. If we find any problems afterwards, I have the tools to fix them. Part of my commitment is to do that. -- Eric S. Raymond