From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Llu=C3=ADs?= Newsgroups: gmane.emacs.devel Subject: Re: Merging CEDET Date: Sun, 03 Jun 2012 23:51:50 +0200 Message-ID: <8762b8awsp.fsf@fimbulvetr.bsc.es> References: <87396ecfyr.fsf@gnu.org> <4FCB6B01.8020600@siege-engine.com> <87aa0kp962.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1338760331 14588 80.91.229.3 (3 Jun 2012 21:52:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2012 21:52:11 +0000 (UTC) Cc: "Eric M. Ludlam" , "Eric M. Ludlam" , Chong Yidong , emacs-devel@gnu.org To: David Engster , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 03 23:52:09 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 1SbIiP-0002Ay-Jk for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2012 23:52:01 +0200 Original-Received: from localhost ([::1]:53664 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbIiP-0006LJ-EB for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2012 17:52:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56377) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbIiM-0006L3-E5 for emacs-devel@gnu.org; Sun, 03 Jun 2012 17:51:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbIiJ-0004As-6V for emacs-devel@gnu.org; Sun, 03 Jun 2012 17:51:58 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:59819) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1SbIiI-0004A7-TV for emacs-devel@gnu.org; Sun, 03 Jun 2012 17:51:55 -0400 Original-Received: (qmail invoked by alias); 03 Jun 2012 21:51:51 -0000 Original-Received: from 185.Red-213-98-218.dynamicIP.rima-tde.net (EHLO localhost) [213.98.218.185] by mail.gmx.net (mp034) with SMTP; 03 Jun 2012 23:51:51 +0200 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX18pnjkgAmwp7lbpcW9vrDCLSeFb8PJRP20M3ZEXy/ zp7ewFggcjQahn In-Reply-To: <87aa0kp962.fsf@engster.org> (David Engster's message of "Sun, 03 Jun 2012 20:00:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.22 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:150762 Archived-At: David Engster writes: > [Eric forgot to include emacs-devel in CC, which is why I'm quoting his > message fully at the end.] > Eric M. Ludlam writes: >> On 06/02/2012 03:47 AM, Chong Yidong wrote: >>> Hello CEDET folks, >>>=20 >>> Is the CEDET file-rename branch ready? If so, now is a good time to >>> start merging into Emacs. >> From the perspective of content, the current trunk in CEDET bzr >> matches up with CEDET 1.1 closely. > To make things clear: I have merged our 'newtrunk' branch (which > included the changes in 'file-rename') into our development trunk. This > means we are now finally working directly with the new file and > directory structure from Emacs, and most changes from Emacs trunk are > now incorporated into CEDET. The original idea was that 2 steps are still missing: - Check which changes in emacs are still missing in cedet's 'file-rename' branch. When done, set that emacs revision in stone, as it will be the ba= se for future merges from emacs to cedet. - Emacs people should check the 'file-rename' branch to manually select any desired changes to integrate into Emacs. When done, set that cedet revisi= on in stone, as it will be the base for future merges from cedet to emacs. Now, David finished stabilizing 'file-rename' in 'newtrunk' (as it contained lots of other changes that were also necessary but not interesting to emacs= ), so I'm no longer sure if 'newtrunk' should be used instead, as it might contain some changes from emacs that are not present in 'file-rename'. > As I've already written some time ago, I've started to write a special > package for merging Emacs<->CEDET. The most important goal is to keep > the granularity of commits in both repositories. For this to work, we > should get our work-flow straight before we start. > My idea is the following and I'd like to hear opinions from the VCS > gurus around here if this is the right approach: > We use three branches: > - CEDET trunk (in the following: 'cedet') > - Emacs trunk (in the following: 'emacs'). Of course, we do not > care for the full Emacs trunk, but only for the CEDET-related > files (essentially: lisp/cedet and lisp/emacs-lisp/eieio*). > - a special branch inside of CEDET upstream (in the following: 'merge= ') > The 'merge' branch is special in that it follows Emacs *and* CEDET > development. It is derived from the old 'file-rename' branch and thus > has a common history with 'cedet', so that we can do proper merges > from and to 'cedet'. > The main concept is this: > - 'merge' follows 'emacs' as close as possible. That means: > - It must *not* have any files from 'cedet' which should not end > up in 'emacs'. Most importantly, this means that *everything* > that is in 'merge' must have signed papers. > - It follows exactly the Emacs directory structure, meaning that > EIEIO is in lisp/emacs-lisp. > - Syncing with 'cedet' happens through *merges*. > - Syncing with 'emacs' happens through *cherry picking*, which with > bzr just boils down to applying patches from "bzr diff -c > ". Alternatively, Llu=C3=ADs "bzr transfer" plugin can be u= sed, > but I couldn't get it to work. Either way, the special > CEDET-Emacs-merge package I've written is used to track which > commits have been merged and which not (and for what reason). > I could think of two alternatives to this approach: > - Drop the special 'merge' branch and directly cherry-pick between the > two repositories, hence essentially do what org and Gnus are > currently doing. However, I think this can only work well if both > repositories are very similar, and CEDET upstream still contains > lots of stuff which isn't in Emacs. > - Use *two* merge branches 'to-emacs' and 'from-emacs', that means one > for each direction and both with a common history with 'cedet'. > This was actually the initial idea, but by now I think this approach > is just over-complicating things and could easily get pretty messy. The initial workflow was (=3D> manual/scripted/whatever operation; -> regul= ar operation): emacs/trunk =3D> cedet/from-emacs This requires renaming some files in the process (I wrote "bzr transplant= " for this specific case). cedet/from-emacs -> cedet/trunk In principle, almost no changes should happen in emacs, so this would req= uire almost no reviews. cedet/trunk -> cedet/to-emacs Not all changes in cedet should immediately go to the next emacs version,= so this would probably be based on cherry-picking. cedet/to-emacs =3D> emacs/trunk This requires renaming some files in the process, too (again, can be automated). For the sake of completeness, if 'file-rename' were used to establish the current synchronization point, under this scheme it would be branched twice= as cedet/{from,to}-emacs. If I understood it correctly, you're proposing to unify branches cedet/{from,to}-emacs. I just think it's less messier to have them separate. Lluis --=20 "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