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 15:17:27 +0900 Message-ID: <87k52wyj9k.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246169857 15196 80.91.229.12 (28 Jun 2009 06:17:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Jun 2009 06:17:37 +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 08:17:30 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 1MKnhg-0003fb-Jm for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2009 08:17:29 +0200 Original-Received: from localhost ([127.0.0.1]:44502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKnhg-0001UU-0C for ged-emacs-devel@m.gmane.org; Sun, 28 Jun 2009 02:17:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MKnhZ-0001SF-21 for emacs-devel@gnu.org; Sun, 28 Jun 2009 02:17:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MKnhT-0001PE-TT for emacs-devel@gnu.org; Sun, 28 Jun 2009 02:17:19 -0400 Original-Received: from [199.232.76.173] (port=59819 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MKnhT-0001PB-Qc for emacs-devel@gnu.org; Sun, 28 Jun 2009 02:17:15 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:38430) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MKnhT-0007Sz-5s for emacs-devel@gnu.org; Sun, 28 Jun 2009 02:17: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 5F5A51537BF; Sun, 28 Jun 2009 15:17:08 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F3FA912827C; Sun, 28 Jun 2009 15:17:27 +0900 (JST) In-Reply-To: <7024025A-9919-46C4-A06E-7878E2116A78@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:111772 Archived-At: David Reitter writes: > On Jun 25, 2009, at 1:48 PM, Stephen J. Turnbull wrote: > > I believe Bazaar now supports fastimport format in both directions. > > > > Interaction between git and Bazaar probably means you lose/munge > > VCS-specific metadata (Bazaar cares about revision numbers while git > > doesn't support them at all, and the revision ID formats are > > timestamp-specific in each VCS, so converting those in a > > roundtrippable way would require great care) in each direction, but > > with minimal care you should be able to preserve the history dag and > > core meta data (author information). > > fast-import (bzr->git at least) keeps an index to facilitate fast > incremental exports. > Suppose one has a commit in the git repo to be committed to the Bzr > repo, would it be possible to > > 1. convert a git patch (git-format-patch) to a Bazaar merge directive? This is software, anything's possible. Useful? Probably not. I don't see why you'd want to do anything other than maintain pairs of bzr-git bidi mirrored branches. In particular, merge directives are most useful if you have a formal review process and a patch queue manager such as Bundle Buggy or PQM. That's just so not Emacs. Emacs has committers, not reviewers. Maybe CEDET has a more formal process, but you still wouldn't want to use merge directives without automatic help AFAICS. > 2. use fast-import/export to export just the patch? I really don't see why you'd want to do this. "Just patches" makes a lot of sense if your name is Andrew Morton. (Not necessarily literally, but someone whose mission in life is managing such a patch-based workflow.) Agreed, compared to ideal, or even to git, bzr's performance sucks, even after a 500% or so speed up in certain operations. But realistically, it's usable, unless you want to hang `(shell-command "$VCS commit -a -m autocommit;$VCS log -10")' on your save-buffer-hook as I do. What bzr cannot do very well that git excels at is editing history. bzr is a FORTRAN derivative. For all practical purposes, unless you're a bzr.dev, history is a linear array in each branch. Unless you really really know what you're doing, you don't want to do anything but work linearly in each branch, and occasionally merge to mainline. But guess what? Most people just want to work linearly in each branch, and occasionally merge to mainline. I see no problem here, do you? git is a LISP derivative. If you are comfortable with cons, setcdr, and mapcar, then you will be comfortable with git-commit, git-rebase, and git-filter-branch. And you will feel the power. But hey, every minute you spend playing with git is a minute you're not hacking Emacs. Is it worth it? 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. If you then find you're not happy yet, *then* it's time to discuss these optimizations. Both git and bzr are flexible enough that you can be confident of finding ways to streamline later if it's necessary.