From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Goals for repo conversion day Date: Sat, 25 Jan 2014 19:15:48 +0200 Message-ID: <83ppngasor.fsf@gnu.org> 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> <20140125160124.GA8171@thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390670172 27427 80.91.229.3 (25 Jan 2014 17:16:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 17:16:12 +0000 (UTC) Cc: schwab@linux-m68k.org, emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 25 18:16:19 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 1W76qA-0001H6-DH for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 18:16:18 +0100 Original-Received: from localhost ([::1]:52003 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W76q9-00082U-Vw for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 12:16:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W76q1-00082K-RP for emacs-devel@gnu.org; Sat, 25 Jan 2014 12:16:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W76pw-0003b0-BH for emacs-devel@gnu.org; Sat, 25 Jan 2014 12:16:09 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:59962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W76pv-0003ar-UP for emacs-devel@gnu.org; Sat, 25 Jan 2014 12:16:04 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZY00400VSXQR00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 25 Jan 2014 19:16:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZY004EZVYOEDB0@a-mtaout20.012.net.il>; Sat, 25 Jan 2014 19:16:01 +0200 (IST) In-reply-to: <20140125160124.GA8171@thyrsus.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:169068 Archived-At: > Date: Sat, 25 Jan 2014 11:01:24 -0500 > From: "Eric S. Raymond" > Cc: schwab@linux-m68k.org, emacs-devel@gnu.org > > 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. With all due respect, this is not necessarily good enough. You have come to the project offering help, but no one gave you the right to make unilateral decisions about these issues. It won't be you who will need to use this data in the years to come. And whatever the other projects which you converted in the past, I doubt that any of them had as long and complex history as Emacs. > > 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. I'd appreciate if you posted the final list of the references, when you are finished with it, so we could have some QA. > > > 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. The problem is not the size of the repository alone. The problem is that different portions of a single changeset were committed many revisions apart. And I don't even understand (and you didn't explain) how will you handle the situation I described above, where a single commit checked in ChangeLog changes for several unrelated commits in the same directory. Which commit clique will you assign the ChangeLog commit to? The devil is in the details, but you haven't provided any details about your plans in this matter. Would you please do that? > 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. Let's agree to keep such low-blow arguments out of this discussion. They aren't fair, and aren't constructive. Let's instead assume that each side knows what they are doing and what they are talking about. > > > 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. See my response above. > > > 5. Unconverted .bzrignores (and possibly .cvsignores) in the history. > > > > Why is that a problem? > > See "seamless history browsing". Sorry, I don't understand. Please elaborate: what is the relation between these ignore files and history browsing? > > 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. Sorry, I don't see how this changes anything. You are still going to make deep changes to the existing mirror. > > 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. Sorry, been there done that. The CVS to bzr conversion also seemed flawless until much later. > If we find any problems afterwards, I have the tools to fix them. Part of > my commitment is to do that. I don't think any of us can in good faith give such promises.