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 16:42:11 +0200 Message-ID: <83vbx8azss.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390660952 27162 80.91.229.3 (25 Jan 2014 14:42:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 14:42:32 +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 15:42:38 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 1W74RS-0006Pc-8O for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 15:42:38 +0100 Original-Received: from localhost ([::1]:51422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W74RR-0001Ke-TT for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 09:42:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W74RK-0001KT-Ov for emacs-devel@gnu.org; Sat, 25 Jan 2014 09:42:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W74RF-0002Pr-NW for emacs-devel@gnu.org; Sat, 25 Jan 2014 09:42:30 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:54200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W74RF-0002Oc-Eu for emacs-devel@gnu.org; Sat, 25 Jan 2014 09:42:25 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MZY00H00OA4FX00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 25 Jan 2014 16:42:23 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZY00HHZOUNA880@a-mtaout21.012.net.il>; Sat, 25 Jan 2014 16:42:23 +0200 (IST) In-reply-to: <20140125140637.GA5631@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.169 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:169058 Archived-At: > 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. 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. > 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. > 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. > 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. > 5. Unconverted .bzrignores (and possibly .cvsignores) in the history. Why is that a problem? > 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). > My quality goals for it include: > > (a) Seamless history browsing. A person looking at the development of > the code should not be distracted by artifacts of VCS changes. This > means clean, properly unified changesets all the way back, properly > converted ignore files all the way back, and commit references that > are not just opaque cookies left over from previous VCSes. > > (b) Information preservation for any future move to another VCS. The > main implication of this goal is not replacing fossil references with > git hashes, as these would present the same problems then that Bazaar > references do now. > > (c) Cryptosigning so that future release integrity is protected and > historical release reconstructions can be trusted (that is, assuming > we don't believe the code history has already been corrupted). > > (d) Avoidance of metadata representations that are easily stripped or > scrambled if someone gets momentarily forgetful in the future. This > is why I don't want to rely on lightweight tags or git notes. 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. So with all due respect, I question the need for this elaborate work, especially since you evidently know very little about the VCS related practices around here, certainly during the bzr age. Comments and opinions by others are welcome.