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: State of the repository conversion Date: Wed, 19 Mar 2014 20:31:45 +0200 Message-ID: <83wqfq82ge.fsf@gnu.org> References: <20140319175124.BCCB3380835@snark.thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1395253905 32101 80.91.229.3 (19 Mar 2014 18:31:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2014 18:31:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: esr@thyrsus.com (Eric S. Raymond) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 19:31:51 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 1WQLHL-0007hI-7a for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 19:31:51 +0100 Original-Received: from localhost ([::1]:43183 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQLHK-00066i-Dk for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2014 14:31:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQLHB-00066R-MW for emacs-devel@gnu.org; Wed, 19 Mar 2014 14:31:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQLH5-0003Ez-7Q for emacs-devel@gnu.org; Wed, 19 Mar 2014 14:31:41 -0400 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:39462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQLH4-0003El-W3 for emacs-devel@gnu.org; Wed, 19 Mar 2014 14:31:35 -0400 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N2P00I004AEL900@mtaout26.012.net.il> for emacs-devel@gnu.org; Wed, 19 Mar 2014 20:30:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2P00EEZ4RATM50@mtaout26.012.net.il>; Wed, 19 Mar 2014 20:30:47 +0200 (IST) In-reply-to: <20140319175124.BCCB3380835@snark.thyrsus.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.182 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:170565 Archived-At: > From: esr@thyrsus.com (Eric S. Raymond) > Date: Wed, 19 Mar 2014 13:51:24 -0400 (EDT) > > >From Eli Zaretskii: > > . I would suggest describing the setup of git-merge-changelog, > because as long as we keep ChangeLog files in the repository, > people might bump into conflicts in the logs, and it would be nice > to avoid that. > > If this is really important to have on the Emacs wiki, someone else will have > to do it. Search engines don't turn up documentation on the tool and I > don't have direct experience with it. The documentation for git-merge-changelog is available as a large commentary at the beginning of the source. Also, someone created a man page out of that commentary and posted it to the gnulib mailing list a week or two ago. > . I think we should discuss some more how to work with the > development trunk and the release branch in parallel, and reflect > the results of the discussion in the Wiki. > > The issue here is that the release branch and the trunk diverge > very quickly after the branch point, and the result is that after > you checkout the other branch, you generally need a very long > build, many times a full bootstrap. While on a modern system, a > full bootstrap should take a few minutes, it is still annoyingly > long, and makes higher the risk of losing the race against other > committers. In addition, you only have a single executable at any > given time, so comparison of behavior between the two branches is > difficult. > > So perhaps we should find a way of having two separate branches, > such that switching between them does not require a build if > nothing changed. > > This is not a documentation request, it's a research agenda. It was a request to discuss and decide upon the recommended workflow. Documenting the decision is the easy part. We did something very similar when we switched from CVS to bzr, and the results are on the wiki. The current Git wiki page simply repeats what the bzr workflow said, which is probably sub-optimal, since Git is not bzr.