From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: patch vs. overwrite in bzr Date: Wed, 04 Apr 2012 14:07:25 -0400 Message-ID: References: <87k42cwys8.fsf@gnu.org> <87limhuldm.fsf@gnu.org> <871uo7g4j6.fsf@gnu.org> <87iphjhbm8.fsf@wanadoo.es> <87398lgrat.fsf_-_@niu.edu> <871uo5c7r0.fsf@wanadoo.es> <87pqbpj5j3.fsf@altern.org> <87aa2szgig.fsf@gnu.org> <87ehs4yrhz.fsf@gnu.org> <83k41vctyg.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1333562881 15914 80.91.229.3 (4 Apr 2012 18:08:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2012 18:08:01 +0000 (UTC) Cc: bzg@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 20:08:00 2012 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 1SFUch-0005HX-Oa for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 20:07:59 +0200 Original-Received: from localhost ([::1]:39990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFUcg-0001Bi-1p for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2012 14:07:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFUcZ-0001B8-31 for emacs-devel@gnu.org; Wed, 04 Apr 2012 14:07:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFUcS-00043u-1F for emacs-devel@gnu.org; Wed, 04 Apr 2012 14:07:49 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:45016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFUcH-000425-4T; Wed, 04 Apr 2012 14:07:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKU/KE9FpZV7/2dsb2JhbACBX5x7eYhwnhmGGQSbGYQJ X-IronPort-AV: E=Sophos;i="4.73,1,1325480400"; d="scan'208";a="172142964" Original-Received: from 69-165-149-123.dsl.teksavvy.com (HELO pastel.home) ([69.165.149.123]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Apr 2012 14:07:25 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 41E8E59339; Wed, 4 Apr 2012 14:07:25 -0400 (EDT) In-Reply-To: <83k41vctyg.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Apr 2012 20:01:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.183 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:149381 Archived-At: >> Yes, 2-way syncin is another issue, one that we need to solve rather >> than get rid of. > If someone could describe the use cases and the requirements and post > that to the bzr mailing list, perhaps we could get some good advice > there, or maybe some useful plugins. Last time I posted about it (several years ago), it didn't elicit much reaction. IIUC it's just difficult to do it "right" because it's largely incompatible with the way metadata/history is kept. The best you can get is good support for two-way sync between identical branches (which is what we all use, where one of the branch is local to our machine and the other is on bzr.sv.gnu.org), but as soon as the two branches are supposed to be different the model breaks down. The problem is similar to cherry-picking, but reversed: you want to be able to get all changes except for a few negative-cherrypicks. E.g, "pull/merge from the Org branch all changes except for those few ones we don't want" (and inversely, they want to "pull from the Emacs branch, except for the file-renamings they did to adapt to their directory layout"). Since the currently supported metadata can't be used, the solution ends up having to be "manual" and can probably work equally well for most VCS. E.g. keep "tags" on both branches that record the last sync, and when a new sync is attempted, get the diff since last sync on each branch (using the tags), apply the patch to the other branch, commit and update the tags. Stefan