From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/69615 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: The Gnus repository is switching to Git as of 2010-04-19 Date: Wed, 21 Apr 2010 12:31:03 +0900 Message-ID: <8739ypmqh4.fsf@uwakimon.sk.tsukuba.ac.jp> References: <878w8jmjly.fsf@lifelogs.com> <87fx2qgrdw.fsf@lifelogs.com> <878w8hevp6.fsf@lifelogs.com> <87aasxmyo8.fsf@uwakimon.sk.tsukuba.ac.jp> <87mxwxmxvg.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271820691 4216 80.91.229.12 (21 Apr 2010 03:31:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Apr 2010 03:31:31 +0000 (UTC) Cc: ding@gnus.org, emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 21 05:31:30 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1O4Qeu-0006FT-Cw for ged-emacs-devel@m.gmane.org; Wed, 21 Apr 2010 05:31:28 +0200 Original-Received: from localhost ([127.0.0.1]:53659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Qet-0000Z1-Om for ged-emacs-devel@m.gmane.org; Tue, 20 Apr 2010 23:31:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4Qen-0000Xc-5Q for emacs-devel@gnu.org; Tue, 20 Apr 2010 23:31:21 -0400 Original-Received: from [140.186.70.92] (port=39871 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Qei-0000Sr-Jt for emacs-devel@gnu.org; Tue, 20 Apr 2010 23:31:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4Qeg-00056x-CI for emacs-devel@gnu.org; Tue, 20 Apr 2010 23:31:16 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:33203) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4Qef-00056b-Sw for emacs-devel@gnu.org; Tue, 20 Apr 2010 23:31:14 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id A11038211; Wed, 21 Apr 2010 12:31:11 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9B5591A34EE; Wed, 21 Apr 2010 12:31:03 +0900 (JST) In-Reply-To: <87mxwxmxvg.fsf@lifelogs.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/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:123957 gmane.emacs.gnus.general:69615 Archived-At: Ted Zlatanov writes: > I don't like the way submodules work. They are good for independent, > fairly static externals but for synchronizing two repositories I think > they'll be a pain. Sure, but you're in for pain anyway since Gnus is a subset of Emacs, not a subtree. That is, Gnus-maintained features are spread across several subdirectories of Emacs, while those Emacs subdirectories also contain non-Gnus content. Gnus contains lisp and etc directories directly, while (I presume) Emacs contains lisp/gnus and etc/gnus directories. I can think of several ways to deal with this, but none of them are very attractive. Of them, I personally would use git submodules because even though I'm sure I'd screw them up occasionally, there would be an exact record of how they got screwed up. The precise semantics of submodules makes the task eminently scriptable, too, so I would expect not to make the same mistake twice.[1] YMMV *What I would do if I were you* is lobby for a new subtree, "packages", of the Emacs tree, and just plop Gnus into that, with its Lisp and support files all under packages/gnus. Add a make rule which puts appropriate Gnus autoloads into the loaddefs or whatever Emacs uses, to find Gnus' Lisp and data in there. (Directory symlinks would work, as in XEmacs' "symlink farm installation" option, but aren't acceptable as long as systems that can't symlink easily are supported.) The way you're going, you're just making the same mistake XEmacs made with its package system (having the installed tree look different from the source tree), except that you're going to have more pain than we do because of the possibility of shooting off both your feet. XEmacs packages has only one source tree, so even though the installed structure is different from the source structure, at least all the hackers are on the same page. This isn't going to be true for Gnus. > There's some unpleasant caveats at > http://book.git-scm.com/5_submodules.html plus they are really easy > to screw up. Sure. It will be work to make them work. But I'm fairly sure you can do it. My point in replying to Stefan is that there's no standard way to do it in Bazaar yet, and the chances are high that the standard, when it appears, will yank the rug out from under existing practice. > SJT> Maybe. I worry about ghost revisions appearing when you do a git->bzr > SJT> sync, and that's where they are most likely since git users branch > SJT> with abandon then abandon the branches, while it's no fun to try to > SJT> work with Bazaar that way. Note that ghost revisions causes nasty > SJT> bugs in bzr as recently as a few weeks ago. > > Using git-bzr from http://github.com/kfish/git-bzr, it seems you can > only push to a single branch, will that still cause problems? I think > the Gnus repository is pretty unlikely to branch with abandon, in any > case. Visibly, no. But you have no control at all over what your developers do privately. Once merged and pushed, those branches have no names in the public repository, but they still exist there! I don't understand how ghost revisions (revisions referenced as parents by revisions in the repo, but which themselves are not present in the repo) can exist at all in a DAG-based system. One may hope that because git doesn't permit that, they won't exist in the bzr mirror of your git tree, and that's actually probably a good bet. But I can't say it can't happen; it's your privilege to place your bets here. > If Yidong, Stefan, and others are concerned about ghost revisions, we > can simply prepare the Gnus -> Emacs synchronization as a patch and > submit it through the usual channels or apply it manually ourselves in > isolation within Bazaar. This will probably be the modus operandi at > first anyhow. Yup. Footnotes: [1] NB. the synch tree would be owned by a special user, and only the update scripts would be allowed to touch it.