From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Syncing Gnus and Emacs repositories Date: Mon, 18 Jun 2007 15:53:09 +0900 Message-ID: <878xahbvoq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <6sps3z32ap.fsf@fencepost.gnu.org> <87tztbcue9.fsf@stupidchicken.com> <87lkemmrg4.fsf@stupidchicken.com> <18033.64249.816850.550250@kahikatea.snap.net.nz> <85ejkcq32v.fsf@lola.goethe.zz> <85k5u4nlrh.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1182148966 21331 80.91.229.12 (18 Jun 2007 06:42:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2007 06:42:46 +0000 (UTC) Cc: emacs-devel@gnu.org, Kenichi Handa To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 18 08:42:44 2007 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 1I0Awl-0006uC-GF for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2007 08:42:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0Awl-0003jU-4C for ged-emacs-devel@m.gmane.org; Mon, 18 Jun 2007 02:42:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I0Awh-0003jN-Re for emacs-devel@gnu.org; Mon, 18 Jun 2007 02:42:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I0Awh-0003jB-2y for emacs-devel@gnu.org; Mon, 18 Jun 2007 02:42:39 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I0Awg-0003j8-Sz for emacs-devel@gnu.org; Mon, 18 Jun 2007 02:42:38 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I0Awd-0006YQ-I2; Mon, 18 Jun 2007 02:42:36 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7564D1535AC; Mon, 18 Jun 2007 15:42:33 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5BB6B1A260E; Mon, 18 Jun 2007 15:53:10 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta27) "fiddleheads" (+CVS-20070324) XEmacs Lucid X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:73213 Archived-At: Eli Zaretskii writes: > > From: Kenichi Handa > > CC: dak@gnu.org, emacs-devel@gnu.org > > Date: Mon, 18 Jun 2007 08:07:28 +0900 > > > > No. I asked to merge unicode-2 into the trunk, but as it > > was not accepted, I asked not to make heavy changes to the > > trunk unless one takes care of emacs-unicode-2 branch too. > > So in that case, making such changes in the Unicode branch directly, > as I suggested, would be a good way of installing changes without > interfering with the future merge, right? Assuming that those making changes in the Unicode branch are thoroughly familiar with it, yes. If (as seems more likely), most developers will split their attention three ways, between 22.x bugfixes, permissible changes to the trunk, and blue-sky changes to the emacs-unicode-2 branch, then people will care most about their own blue-sky changes, and know very little about regressions in emacs-unicode-2, until pointed out to them. But emacs-unicode-2 will be a branch, still, and will not get so much testing. The risk of regression in emacs-unicode-2 work seems substantial. If I were Handa-san, I would resist opening that branch to commits related to work that could be done in non-emacs-unicode-2 branches. Also, David Kastrup is quite right about the deficiencies of CVS. XEmacs did something similar to what is being proposed here. Under pressure from people who were not primarily interested in the 21.4 release, we branched in January 2001, pushing blue-sky projects off on a branch, and keeping 21.4 on the trunk. It immediately became clear this was unsustainable due to the difficulty of using cvs annotate, cvs diff, and cvs update -j with mainline on a CVS branch. So in April 2001, less than three months later, we transplanted the trunk (starting from the fork) to a new release-21-4 branch, and the 21.5 branch back to the trunk, at fairly high cost in current usefulness of annotate, diff and update -j. However, with mainline on the branch, that cost was increasing rapidly, while with mainline on the trunk, the cost decreased to negligible by the end of summer 2001. While in the end we avoided total disaster, the rationalization effort was unaccompanied by any net benefit whatsoever, in fact, there were net costs both before and after the rationalization compared to doing it right by putting mainline on the trunk as soon was the 21.4 feature freeze was implemented. Caveat: as of CVS 1.12 or so, the -r TAG:DATE option format is available. This might mitigate the very strong bias of CVS in favor of comparisons with and merges to trunk. However, because of the structure of ,v files, there is no question that after a few hundred commits work that involves both mainline and another branch will become painfully inefficient. N.B. Emacs's situation is somewhat different from XEmacs 21.4, as people seem willing to accept an across-the-board freeze during the release cycle. However, given that the EMACS_22_BASE branch now exists, IMO *all* large merges and other potentially destabilizing changes should be done to the trunk where they will get maximum testing; the only question is whether they should be synchronized to events in Emacs 22 for some reason, or whether the trunk should be opened now to merge of emacs-unicode-2 and so on, subject to negotiation among the developers working on the trunk (ie, not considering effects on Emacs 22). Bottom line: The risks are high, the benefits are small. I strongly recommend against doing substantial work on a CVS branch, unless it has a single theme and is explicitly aimed at a single merge to mainline, then retirement. If Richard sustains his veto of merging emacs-unicode-2 and other potentially destabilizing work on the trunk, then, based on that experience, I see only two practical choices. (1) Accept that the trunk will stay in feature slush for a while, and work on the branch(es) that interest you in separate workspaces until permission is given to merge to trunk. (2) Switch to a distributed SCM like Arch or git for cooperative work on merged workspaces, and use CVS only to maintain continuity of communication with the rest of the world and those whose current work is focused on the 22.x branch or features admissible on the trunk in CVS. (Subversion is not a panacea here.)