From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Thu, 13 Mar 2008 10:04:54 +0100 Message-ID: <874pbbyoy1.fsf@ambire.localdomain> References: <87skyvse7k.fsf@xmission.com> <87fxuvl0gi.fsf@offby1.atm01.sea.blarg.net> <87bq5j19ok.fsf@workhorse.earlhome> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1205399303 23709 80.91.229.12 (13 Mar 2008 09:08:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Mar 2008 09:08:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: dhruva Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 13 10:08:50 2008 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 1JZjQd-0007p4-8I for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 10:08:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZjQ4-0001qB-7c for ged-emacs-devel@m.gmane.org; Thu, 13 Mar 2008 05:08:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JZjP7-0001Q9-PR for emacs-devel@gnu.org; Thu, 13 Mar 2008 05:07:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JZjP4-0001PU-6T for emacs-devel@gnu.org; Thu, 13 Mar 2008 05:07:12 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JZjP3-0001PB-K5 for emacs-devel@gnu.org; Thu, 13 Mar 2008 05:07:09 -0400 Original-Received: from [151.61.142.209] (helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JZjP2-00012l-Ry for emacs-devel@gnu.org; Thu, 13 Mar 2008 05:07:09 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1JZjMs-0005q8-Gj; Thu, 13 Mar 2008 10:04:54 +0100 In-Reply-To: (dhruva's message of "Thu, 13 Mar 2008 13:34:56 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:92383 Archived-At: () dhruva () Thu, 13 Mar 2008 13:34:56 +0530 IMHO, the performance aspects must be considered seriously. If performance can't be engineered into the entire system, the usual (serious) way to do it is to use hierarchy to partially separate the slow parts from the fast parts. CPU <-> L[1...n]-CACHE <-> MEMORY <-> DISK <-> NETWORK Here, CPU can spin as fast as it wants. It is not limited by speeds between other elements of the hierarchy, apart from L1-CACHE, and yet can (if All Goes Well :--) conduct useful dialogue w/ NETWORK anyway. I think a similar arrangement is best for my case: ttn <-> git <-> bzr <-> emacs@internet Since i cannot make bzr faster, i do my local spinning w/ Git. Presently, i'm still (half-heartedly) searching for the git/bzr gateway, hoping someone will post a url... btw, i see there is already some thought on the problem for Git and Mercurial: . For the email-only crowd, on that webpage, Theodore T'so sez: | So basically git does have short-comings, yes, but people will | come out in different places about which tools is best for them, | and that=92s OK. Actually, I think the ultimate solution for this | problem is to build a bidrectoinal hg/git gateway. There are | tools that will export from hg to git, and vice versa, and they | are actually pretty sophisticated. I don=92t think it should be | that painful to create a tool that does incremental exports in | both directions, maintaining state so that the right thing | happens when a commit gets made on the git side, and gets | exported into hg, or vice versa. Ultimately I think that=92s the | best solution, since that way people can use whatever tool they | want, and still contribute and development as first class | citizens. This is the main reason why I=92ve held off on | converting e2fsprogs to git (although I have made some private | test repositories which I=92ll use to take advantage of git=92s | superior annotation and query/log utilities); I don=92t want to | make a git repository of e2fsprogs public until I=92m sure that a | bidrectional gateway tool won=92t require me to make any changes | that affect the commit-id=92s, since that would invalidate any | work that people have done that was based on a clone of the | coverted git repository. | | I have a rough design for how to do the bidirectional gateway, | but the issue is finding time to implement it. Anyone with free | time looking for a project? If so, contact me. I probably should | have written this up as a potential Google Summer of Code | project, but it=92s too late for this year. Oh, well. IMHO, it's just a matter of time until some Righteous Hacker stitches it all together. It's a nice problem. thi