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: Switching CEDET from CVS to a Distributed VCS. Date: Sun, 28 Jun 2009 23:04:29 +0900 Message-ID: <877hywxxn6.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1245882173.24086.14.camel@projectile.siege-engine.com> <87r5x8xl04.fsf@uwakimon.sk.tsukuba.ac.jp> <7024025A-9919-46C4-A06E-7878E2116A78@gmail.com> <87k52wyj9k.fsf@uwakimon.sk.tsukuba.ac.jp> <6314DBFC-0104-4EFC-8CFE-B023E929C9B9@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246197873 16868 80.91.229.12 (28 Jun 2009 14:04:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2009 14:04:33 +0000 (UTC) Cc: Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 28 16:04:26 2009 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 1MKuzZ-00030w-S1 for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2009 16:04:26 +0200 Original-Received: from localhost ([127.0.0.1]:60637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKuzZ-0007Kv-9M for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2009 10:04:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKuzU-0007Kq-Nx for emacs-devel@gnu.org; Sun, 28 Jun 2009 10:04:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKuzQ-0007Ke-2g for emacs-devel@gnu.org; Sun, 28 Jun 2009 10:04:20 -0400 Original-Received: from [199.232.76.173] (port=42457 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKuzP-0007Kb-WE for emacs-devel@gnu.org; Sun, 28 Jun 2009 10:04:16 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:39143) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKuzP-0004Wx-1y for emacs-devel@gnu.org; Sun, 28 Jun 2009 10:04:15 -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 B80F31537B5; Sun, 28 Jun 2009 23:04:12 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A925D12827C; Sun, 28 Jun 2009 23:04:29 +0900 (JST) In-Reply-To: <6314DBFC-0104-4EFC-8CFE-B023E929C9B9@gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.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:111781 Archived-At: David Reitter writes: > On Jun 28, 2009, at 2:17 AM, Stephen J. Turnbull wrote: > > >> 1. convert a git patch (git-format-patch) to a Bazaar merge > >> directive? > > > > This is software, anything's possible. > > I looked into it and it's fairly easy to do. It would be for local > use rather than for review by e-mail. Instead of parsing the patch and/or log for meta data, applying the patch and committing with "bzr commit"? That's creative. Good idea, and good luck with it, it deserves a try. > > Useful? Probably not. OK, I retract that. > > Seriously, if you're a git aficianado, set up the bidirectional > > mirror, create a pushthrough script that pushes from the git repo to > > the local bzr repo, and on from the local bzr repo to Emacs Central, > > and (my best guess) be happy. > > This would be the ideal case and very, very convenient. I hope there > will be such a mirror [on savannah if possible], This would be an amazing time sink for the Savannah people, is my guess. Not a good idea -- a lot of people would use it and conflicts would be frequent, I think. The extra bzr repos will stay way under 1GiB for the forseeable future, it's just not a big deal to keep them locally. Savannah should maintain the official format, period. In theory you could use incremental fastimport format as a wire protocol, but I wouldn't want to try that without core support from the bzr devs. Given how much effort they put into protocol and format proliferation, I doubt they'd be happy to restrict themselves to a simple NIH protocol. > but I'm not sure how it would handle merge failures, assuming that > this sync script runs periodically and without user intervention. If it runs locally on your box while you're not working, it should rarely have bad conflicts, and you should be able to resolve them manually without trouble. > The more frequently the git mirror is updated, the less likely it > is that a git->bzr merge fails. If it does fail, I'm not sure how > to handle it well. That's why I didn't pursue the idea so far. The git->bzr pushthrough script would try to do a bzr->git merge first, of course. You want *all* failures to happen in your local git repository because that's where you want to deal with amending commits and similar history manipulations. If that doesn't excite you, learn to use bzr. Trying to maintain bidirectional synchronization is going to drive somebody crazy.