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: VC mode and git Date: Mon, 30 Mar 2015 02:53:04 +0900 Message-ID: <87d23rk7wf.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86egoeusg2.fsf@example.com> <87384qzxqy.fsf@igel.home> <87h9t4kcaq.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1427651617 8602 80.91.229.3 (29 Mar 2015 17:53:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Mar 2015 17:53:37 +0000 (UTC) Cc: sva-news@mygooglest.com, schwab@suse.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 29 19:53:22 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YcHOj-00027k-MD for ged-emacs-devel@m.gmane.org; Sun, 29 Mar 2015 19:53:21 +0200 Original-Received: from localhost ([::1]:57757 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcHOj-0001gQ-5L for ged-emacs-devel@m.gmane.org; Sun, 29 Mar 2015 13:53:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcHOf-0001gB-Kj for emacs-devel@gnu.org; Sun, 29 Mar 2015 13:53:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcHOc-0003RV-DK for emacs-devel@gnu.org; Sun, 29 Mar 2015 13:53:17 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcHOc-0003QF-3C; Sun, 29 Mar 2015 13:53:14 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 74F021C3860; Mon, 30 Mar 2015 02:53:04 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 49D8D120EC9; Mon, 30 Mar 2015 02:53:04 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184520 Archived-At: Richard Stallman writes: > Karl Fogel and I wrote a modern > > workflow (one which is used successfully by many many developers in > > projects using DVCSes), > > Felicitations for them, but why should that be relevant to this issue. It's relevant because Emacs needed a DVCS, many Emacs developers needed a distributed workflow, there are *many* possible workflows, and it made sense to describe one that is proven to be successful and adapted to the needs of a great many developers in some very active projects. Describing several is known to confuse people, and worse, they often try to pick and choose parts of different workflows without understanding them. > There is a reason why some people like that workflow, and a reason > why it screwed me. You seem to be confused here. The popular workflow referred to above has nothing to do with the GitForEmacsDevs workflow as far as I know (I had nothing to do with GitForEmacsDevs). And it wasn't the GitForEmacsDevs workflow that screwed you, either, as you yourself testify that you didn't follow it accurately at least in respect of pushing after committing. Evidently you were using some homebrew workflow that may, or may not, have closely resembled GitForEmacsDevs. > > Fortunately, you guys were quite late to the party, > > and everybody else either used a DVCS-enhanced workflow already, or > > read the original BzrForEmacsDevs with the DVCS-enhanced workflow. > > If that happened, what is fortunate about it? You seem to be > campaigning to make people stop using CVS-style workflow, even if > it is good for them. Make existing users stop, no, I think you are confusing me with ESR (among others). I don't care if you change, that's your decision to make. Since you evidently are no longer an active developer, I don't even really see any advantages for anybody in you switching to a distributed workflow. But you're a very unusual case. Discourage new developers from using CVS-style workflows, and encourage developers who have not yet tried distributed workflow to try it, yes, I do intend that. The CVS-style workflow may be good for some individuals. In your case, a long-standing workflow that doesn't seem to benefit from local commits, and you have a privileged position: no one is going to tell you not to commit whatever you want to commit to mainline. And you're used to waiting for a window to commit. It's perfect for you. That isn't true of most Emacs developers, especially those working on more extensive changes -- most prefer *not* to check in to the public repository until they have a beta-quality complete change, but they *do* want to commit so they can move on to another task (perhaps related and intended to be pushed at the same time, perhaps not). A distributed workflow gives them the benefits of version control without interfering with the project mainline or vice versa, until they're ready to integrate. Furthermore, having most developers on a distributed workflow is a lot less frustrating during peak periods such as just before a feature freeze. I remember well the annoyance of having somebody commit just as I was ready to do so, and having to resolve a pile of irrelevant conflicts in files I wasn't ready to commit just to make CVS happy.[1] Worse, a developer would often have a queue of patches, and commit them one after another at several minutes interval between commits. In a DVCS, you can commit at will with intervals of seconds, minutes, or hours, but the push always takes the same amount of time, normally a few seconds. Your push may still fail, and you'll need to merge locally and try again, but the windows for successful push are longer. > We can see that also in the sneer-word "modern", which is further > name-calling. "Modern" in my usage above simply means "adapted to tools developed more recently than CVS." I live in Asia, where tradition is appreciated and "modern" is not necessarily a compliment, and certainly didn't mean to sneer at your use of VCS. Footnotes: [1] I never used svn in anger, it might be better in this respect. But in CVS it could be a real PITA.