From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kolo Rahl Newsgroups: gmane.emacs.devel Subject: Re: On the subject of Git, Bazaar, and the future of Emacs development Date: Wed, 27 Mar 2013 20:22:19 -0700 Message-ID: References: <87y5d9p5td.fsf@dex.adm.naquadah.org> <87vc8dtbcb.fsf@lifelogs.com> <871ub1gmdf.fsf@engster.org> <87d2ulovd0.fsf@dex.adm.naquadah.org> <85r4j0h1ww.fsf@member.fsf.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd75bb885619b04d8f3a98c X-Trace: ger.gmane.org 1364440948 26576 80.91.229.3 (28 Mar 2013 03:22:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 03:22:28 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 28 04:22:54 2013 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 1UL3QT-0006GB-CH for ged-emacs-devel@m.gmane.org; Thu, 28 Mar 2013 04:22:53 +0100 Original-Received: from localhost ([::1]:35131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3Q5-00068m-89 for ged-emacs-devel@m.gmane.org; Wed, 27 Mar 2013 23:22:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3Pz-00068c-F7 for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:22:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UL3Pw-00072x-Iw for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:22:23 -0400 Original-Received: from mail-ia0-x229.google.com ([2607:f8b0:4001:c02::229]:52421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UL3Pw-00072q-E9 for emacs-devel@gnu.org; Wed, 27 Mar 2013 23:22:20 -0400 Original-Received: by mail-ia0-f169.google.com with SMTP id j5so8066152iaf.28 for ; Wed, 27 Mar 2013 20:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=U/vkP0q/auY4TBLFqzO1SP/WJsWIYnu2RAMbr+KL5bE=; b=OefRnTlE3A5zUxhJqebtS9GiTcfLXxv2Nv06Np/a+EMOYMlmJTYybEZnENfdqxJwDU 7qkBtBxgQHLiE+vXEGe3X0eCiurUfpCWJ+h2B6lTD3WnmwFD/iF3hZmqvL57eZzC4BN+ XN5pU5IqqYrOphVjOtof+JNCZ3KYHyFHKj9IZwlOxwIc6OVSaN6P+3uKzjmFJ8lsvghF 0r+02/8OFCgMykdPnHqHQMLoJZ1qtmZ0a6ylYfRLmEYFjY/ZWccJO3xyHIXas/o9CCBm bj4FPv3XxWhk0IY10eV1A9ldDtYDDktEmcdLOsXGDUkKFStVfGiGI1S+NejEF6Nf1ZPJ eaDA== X-Received: by 10.50.20.7 with SMTP id j7mr6049275ige.10.1364440939582; Wed, 27 Mar 2013 20:22:19 -0700 (PDT) Original-Received: by 10.64.11.2 with HTTP; Wed, 27 Mar 2013 20:22:19 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::229 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:158332 Archived-At: --047d7bd75bb885619b04d8f3a98c Content-Type: text/plain; charset=ISO-8859-1 Question about these "bidirectional" merge situations: how often do they happen and what is an example of one? I'm honestly curious, as it seems that such a development flow would imply a cyclic set of dependencies between the two branches. A _needs_ to be in sync with B only if it has a dependency on work in the B branch and vice versa, so if A and B branches both need to be constantly sync'd with each other, that means they have cyclic dependencies, right? On Wed, Mar 27, 2013 at 7:43 PM, Stefan Monnier wrote: > >> The core of the problem is bidirectional merging. > > If I understand what you mean by "bidirectional merging", then monotone > > handles it nicely (http://www.monotone.ca/). > > By bidirectional merging, I mean that you have two parallel branches > that should be kept in sync, so that any commit on branch A should be > sync'd to branch B and vice versa. Yet branch A and branch B are not > identical (there's a "constant" diff between the two). > > > Stefan > > --047d7bd75bb885619b04d8f3a98c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Question about these "bidirectional" merge situa= tions: how often do they happen and what is an example of one? I'm hone= stly curious, as it seems that such a development flow would imply a cyclic= set of dependencies between the two branches. A _needs_ to be in sync with= B only if it has a dependency on work in the B branch and vice versa, so i= f A and B branches both need to be constantly sync'd with each other, t= hat means they have cyclic dependencies, right?


On Wed, Mar 2= 7, 2013 at 7:43 PM, Stefan Monnier <monnier@iro.umontreal.ca>= ; wrote:
>> The core of the p= roblem is bidirectional merging.
> If I understand what you mean by "bidirectional merging", th= en monotone
> handles it nicely (http://www.monotone.ca/).

By bidirectional merging, I mean that you have two parallel branches<= br> that should be kept in sync, so that any commit on branch A should be
sync'd to branch B and vice versa. =A0Yet branch A and branch B are not=
identical (there's a "constant" diff between the two).


=A0 =A0 =A0 =A0 Stefan


--047d7bd75bb885619b04d8f3a98c--