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: Incorrect merge Date: Wed, 03 Nov 2010 03:34:52 +0900 Message-ID: <87eib3wp4j.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4CCEC526.3070502@cornell.edu> <87aaltc9rc.fsf@stupidchicken.com> <83pqup53qb.fsf@gnu.org> <83fwvk6arf.fsf@gnu.org> <87hbg0jxyu.fsf@uwakimon.sk.tsukuba.ac.jp> <87d3qnk9am.fsf@telefonica.net> <87k4kvwu6w.fsf@uwakimon.sk.tsukuba.ac.jp> <8762wfk5r0.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1288722807 5485 80.91.229.12 (2 Nov 2010 18:33:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 2 Nov 2010 18:33:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 02 19:33:23 2010 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.69) (envelope-from ) id 1PDLfc-0007Zc-Cw for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 19:33:20 +0100 Original-Received: from localhost ([127.0.0.1]:52158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDLfb-0000nt-Dy for ged-emacs-devel@m.gmane.org; Tue, 02 Nov 2010 14:33:19 -0400 Original-Received: from [140.186.70.92] (port=58145 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDLfU-0000n2-Ti for emacs-devel@gnu.org; Tue, 02 Nov 2010 14:33:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDLfT-0001kF-K6 for emacs-devel@gnu.org; Tue, 02 Nov 2010 14:33:12 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:40820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDLfT-0001jw-2h for emacs-devel@gnu.org; Tue, 02 Nov 2010 14:33:11 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id AC1232AF543; Wed, 3 Nov 2010 03:33:08 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 9C8CA2AF542; Wed, 3 Nov 2010 03:33:08 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 8FF4F3FA0530; Wed, 3 Nov 2010 03:33:08 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A9FFD1A3EDD; Wed, 3 Nov 2010 03:34:52 +0900 (JST) In-Reply-To: <8762wfk5r0.fsf@telefonica.net> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:132293 Archived-At: =D3scar Fuentes writes: > Adding an extra branch does not increase the current workload. Of course it does. Most occasional developers work only on the branch that they use every day, either trunk or stable/maintenance. That's where they test, that's where they refine. Adding the common-fixes branch means they need to clone and maintain that branch, and work in a branch that they don't use. Even for frequent contributors who help with porting patches back and forth between the branches, this requires more thinking about where you should do the work. > They would commit to common-fixes the same way they do for emacs-23. You mean, stuff that doesn't belong there, as started this thread? ;-) > If the set of people who don't want to learn determines how the project > is managed, It already has, in both the choice of BTS and the choice of dVCS. In the sense that in both cases the ability to continue with basically the same flow, even if implemented with slightly different commands, was a crucial requirement in choice of software. > And I think that you'll find quite harder to implement it on bzr > than on SVN. Depends on what you mean. The basic functionality we're talking about here, blocking certain revisions from being merged or cherry-picked, depends on a globally unique revision ID. In a centralized system, there's only one authority, so there's no problem. In a dVCS you have to contrive one, but all the dVCSes have one. So I don't think it's any harder in this sense. On the other hand, this can really only be enforced at push time. So a developer could make several commits in a branch that is blocked from merging before realizing it. That would be inconvenient, and it's not obvious to me how to work around. But I don't think it would be more than an inconvenience. Finally, although right now Emacs doesn't have the skills AFAIK, in the long run implementing for Bazaar might be far more powerful since the script could be adapted from svnmerge.py, written in Python, and thus have direct access to Bazaar's internal information. Maybe even as a plugin. > It is quite pathetic to even consider using hacks that workaround > the limitations of simplistic VCS like svn Call it what you like; however, the fact is that Emacs has chosen to use a workflow that emphasizes Bazaar's ability to work like a centralized system. Individual developers can use the decentralized features as they like, but the project workflow does not mandate them. > when there are standard practices on dVCS for properly solving the > problem at hand. But there aren't. Only Darcs supports cherry-picking properly. And as an add-on hack, svnmerge.py does. The revision-oriented systems don't implement the necessary accounting. What is available for the revision-oriented dVCSes is a set of workflows that *mostly* avoid creating a problem, but have their own inconveniences. I suspect the Emacs community will prefer to implement a tool that codifies their workflow and adds certain features such as true cherry-picking and blocking revisions, to changing the workflow.