From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Tue, 18 Mar 2008 18:14:53 -0700 Message-ID: <47E0690D.7010504@emf.net> References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> <47DA3601.3040507@arbash-meinel.com> <87r6ecsww7.fsf@uwakimon.sk.tsukuba.ac.jp> <200803180148.m2I1m0dB003724@sallyv1.ics.uci.edu> <87myov39k5.fsf@stupidchicken.com> <47E05AA3.6060306@emf.net> <20080318171709.2fc65141@reforged> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205886973 16443 80.91.229.12 (19 Mar 2008 00:36:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Mar 2008 00:36:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Mike Mattie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 19 01:36:42 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 1JbmIL-0004Uw-Fy for ged-emacs-devel@m.gmane.org; Wed, 19 Mar 2008 01:36:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbmHl-0007hy-BC for ged-emacs-devel@m.gmane.org; Tue, 18 Mar 2008 20:36:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JbmHh-0007fl-6R for emacs-devel@gnu.org; Tue, 18 Mar 2008 20:36:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JbmHg-0007f1-Em for emacs-devel@gnu.org; Tue, 18 Mar 2008 20:36:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JbmHg-0007ep-7C for emacs-devel@gnu.org; Tue, 18 Mar 2008 20:36:00 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JbmHg-0001uC-1x for emacs-devel@gnu.org; Tue, 18 Mar 2008 20:36:00 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 25847286; Tue, 18 Mar 2008 17:35:45 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <20080318171709.2fc65141@reforged> X-detected-kernel: by monty-python.gnu.org: 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:92949 Archived-At: Mike Mattie wrote: > If you were going to invest your time and skills into hacking on a VCS do you > really want to choose coding out-of-tree scripts for CVS ? > The question of making short-term investments of my time in this area has been weighing heavily on my mind, lately. The original Arch took like 4-6 weeks to code and, now, years later, I know a lot more. So I'm trying to think of what I might do in this area. I don't think I want to make any programs that are CVS-specific in any way -- but I am thinking that the "dcvs" needs of a project like Emacs can possibly be done in a way that doesn't make it necessary to first move away from CVS. Desirable to eventually move away, absolutely -- but i'm not sure that good dcvs features need to force that migration to happen right away. > Any ideas that would retro-fit DVCS features onto archaic VCS systems > would be more effective for Emacs in vc I think. From there you could > at least expect a normalized API for common VCS operations and a larger > audience for your features. > > It seems better to work on a better future for a modern VCS system, all things equal, > than working on arranging the flowers at CVS's funeral. > > Sure. I'm not proposing to invest in CVS' future. I'm suggesting working on dvcs needs with the constraint that it's desirable to meet dcvs needs without *forcing* a migration away from CVS (or any other system). It's best, to the extent possible, for dvcs features to be independent of the vcs system used by each programmer. > Your analysis from the Shift Selection thread is meticulous IMHO, this must be > a floater (idea). > > The VCS stuff is, *yes* a "floater" speculative idea. The shift-select stuff is, ahem, well... as you say, thank you. I'm sketchy about the concept of trying to muster volunteer labor. But I'm a little bit hooked in interest on the dcvs woes here. I'm just wondering what makes sense to try to do here. Whether I can mount a quick and dirty "Arch 2.0" push to any good effect. -t > btw, I have coded some large shell scripts regretfully. Even basic string operations are > not simple ; hence perl. I doubt that any fancy merging tricks can emerge in sane > form without writing a FOO -> bash compiler. > > The auto-tools suite is essentially useful, but I doubt anyone is thrilled by > maintaining autoconf. > > even if you get daring and use co-processes to leverage an external "to bash" > translator to feedback complex semantics into your bash core, many, > if not most programs cannot read from pipes without SIGPIPE. The mmap assumption > is almost universal these days. > > If you need any more horror stories along these lines, I will share them privately :) > > >> -t >> >> >> >> >> >>> >>> >> >>