From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?TGx1w61z?= Newsgroups: gmane.emacs.devel Subject: Keeping changes in sync with upstream projects Date: Tue, 18 May 2010 20:05:55 +0200 Message-ID: <86zkzxccfw.wl%lluis@ginnungagap.pc.ac.upc.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: dough.gmane.org 1274206399 5790 80.91.229.12 (18 May 2010 18:13:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 18 May 2010 18:13:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 18 20:13:18 2010 connect(): No such file or directory 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 1OERI4-0004ml-0r for ged-emacs-devel@m.gmane.org; Tue, 18 May 2010 20:13:16 +0200 Original-Received: from localhost ([127.0.0.1]:43599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OERI3-0007OV-77 for ged-emacs-devel@m.gmane.org; Tue, 18 May 2010 14:13:15 -0400 Original-Received: from [140.186.70.92] (port=49599 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OERB5-0002gd-1i for emacs-devel@gnu.org; Tue, 18 May 2010 14:06:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OERB3-0008BD-00 for emacs-devel@gnu.org; Tue, 18 May 2010 14:06:02 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:47709) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OERB2-0008Aw-3B for emacs-devel@gnu.org; Tue, 18 May 2010 14:06:00 -0400 Original-Received: (qmail invoked by alias); 18 May 2010 18:05:54 -0000 Original-Received: from unknown (EHLO localhost) [84.88.50.48] by mail.gmx.net (mp056) with SMTP; 18 May 2010 20:05:54 +0200 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX1+VR0wXSaSVq/4p9Zaw0RK6dwYORZADuTVDrnlnzj FPc1AZ3/VZ6Ay3 User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/24.0.50 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:124905 Archived-At: This is something that I've wanted to ask since quite a long time, and now that CEDET 1.0 seems to be closer, it is time to think of a solution. So, the problem: Emacs ships with code from other relatively large projects that have their own upstream repositories. Synchronizing emacs upstream to/from those project's upstream should be as automated as possible (i.e., it is not desirable to diff emacs' version with upstream's and integrate changes manually). High-level requirement: Sync back and forth emacs' upstream with project's on a per-project basis. Specific requirements: * Sync an emacs subtree with project's upstream (assuming such projects have a subtree of their own on emacs upstream) * Keep track (on one or both sides of) of "remote" changesets: * merged * discarded * temporally hold (cherrypicking) I think this would cover most aspects of cross-project syncing, and after talking with Eric (some time ago), there is no problem for CEDET to switch from its current CVS into another VCS. My question is, which VCS should be used and how in order to facilitate merges between emacs and this kind of projects (CEDET, in this case)? Because, frankly, I had a real bad time manually merging changes from emacs trunk into CEDET :) If I remember well, bazaar has no support for subtree merging nor changeset cherrypicking, although I might well be completely wrong. Any ideas on how to ease it? I can think of tagging "local" changesets with references to "remote" changesets, but this would need some specialized tools. For example, if Emacs were in subversion, and the project to sync was in its own subtree, I could add three properties to the root of the subtree (svn propedit): * remote repository URI * merged changesets * discarded changesets * hold changesets Then a script can be written to check all changesets on the remote repository that are not listed on any of the other three properties, meaning that they are pending for merge. Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth