From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Switching to Subversion Date: Mon, 13 Nov 2006 13:55:47 +0100 Message-ID: <85wt5ztsj0.fsf@lola.goethe.zz> References: <87mz6y8y3j.fsf@catnip.gol.com> <87bqne87ur.fsf@catnip.gol.com> <10609.1163264429@olgas.newt.com> <87fycphhyr.fsf@pacem.orebokech.com> <87odrdzci9.fsf@olgas.newt.com> <87ac2w45e0.fsf@catnip.gol.com> <85y7qfvigo.fsf@lola.goethe.zz> <85psbrvgrt.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1163422589 22275 80.91.229.2 (13 Nov 2006 12:56:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2006 12:56:29 +0000 (UTC) Cc: thomas@intevation.de, Bill Wohler , Juanma Barranquero , emacs-devel@gnu.org, rms@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 13 13:56:25 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GjbMI-0001B5-JY for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2006 13:56:18 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjbMH-0000lX-W6 for ged-emacs-devel@m.gmane.org; Mon, 13 Nov 2006 07:56:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GjbM6-0000ku-Is for emacs-devel@gnu.org; Mon, 13 Nov 2006 07:56:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GjbM5-0000kV-FK for emacs-devel@gnu.org; Mon, 13 Nov 2006 07:56:06 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GjbM5-0000kK-3q for emacs-devel@gnu.org; Mon, 13 Nov 2006 07:56:05 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GjbM5-0006z0-4Q for emacs-devel@gnu.org; Mon, 13 Nov 2006 07:56:05 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GjbLw-0005tl-VI; Mon, 13 Nov 2006 07:55:57 -0500 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 808D91CD9DA7; Mon, 13 Nov 2006 13:55:47 +0100 (CET) Original-To: Sascha Wilde In-Reply-To: (Sascha Wilde's message of "Mon\, 13 Nov 2006 13\:38\:30 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (gnu/linux) 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:62205 Archived-At: Sascha Wilde writes: > David Kastrup wrote: > >> Sascha Wilde writes: >> >>> But on the other hand: Emacs Developers will be using the >>> development version anyway, so integrating mercurial support shortly >>> after the release should be sufficient. >> >> Disagree. Shortly after the release, development versions can be >> expected to be hosed temporarily, and the only Emacs version one >> can depend on to work reliably is the last released one. >> >> If you can't work the SCM from a _stable_ version of Emacs, it is a >> mess to get back on track. [...] > The most important point is: we shouldn't base a decision for or > against a new SCM on that question, especially not when there _is_ > support for Emacs available and the supporting modes are just not > part of Emacs yet. Disagree. > In fact, at this point of time there is no support for most free > distributed SCMs (git, bazar, bazar ng, darcs, monotone, mercurial > ...) in stock Emacs, it would be a big loss if this would be a > reason to rule out all of them. Disagree. We need stability, dependability and a proven track record for interaction with Emacs. We don't have the manpower to fix a bad choice. A lack of a well-established feasibility for large-scale projects in combination with Emacs and a number of operating systems is, in my opinion, a definite reason to rule out any system. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum