From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: State of the CEDET merge Date: Sat, 12 Mar 2011 08:15:45 -0500 Message-ID: <4D7B7201.6050208@siege-engine.com> References: <877hc7lzcc.fsf@fencepost.gnu.org> <8762rq7w7h.fsf@stupidchicken.com> <871v2en9n1.fsf@fencepost.gnu.org> <871v2eyece.fsf_-_@engster.org> <87r5ad91dm.fsf@ginnungagap.bsc.es> <87zkp1solk.fsf@fencepost.gnu.org> <87wrk54pzp.fsf@ginnungagap.bsc.es> <87lj0kr7y3.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1299935765 18428 80.91.229.12 (12 Mar 2011 13:16:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Mar 2011 13:16:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 12 14:16:00 2011 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 1PyOfn-0006SL-Cg for ged-emacs-devel@m.gmane.org; Sat, 12 Mar 2011 14:16:00 +0100 Original-Received: from localhost ([127.0.0.1]:43481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyOfl-0007sP-Ez for ged-emacs-devel@m.gmane.org; Sat, 12 Mar 2011 08:15:57 -0500 Original-Received: from [140.186.70.92] (port=49244 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PyOfe-0007rz-Sh for emacs-devel@gnu.org; Sat, 12 Mar 2011 08:15:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PyOfd-00009A-UF for emacs-devel@gnu.org; Sat, 12 Mar 2011 08:15:50 -0500 Original-Received: from bird.interbax.net ([75.126.100.114]:40955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PyOfd-00008Y-Or for emacs-devel@gnu.org; Sat, 12 Mar 2011 08:15:49 -0500 Original-Received: (qmail 21954 invoked from network); 12 Mar 2011 07:15:46 -0600 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net (HELO ?192.168.1.201?) (71.184.83.10) by interbax.net with SMTP; 12 Mar 2011 07:15:46 -0600 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre In-Reply-To: <87lj0kr7y3.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Windows 98 (1) X-Received-From: 75.126.100.114 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:137151 Archived-At: On 03/12/2011 04:42 AM, David Kastrup wrote: > Lluís writes: > >> David Kastrup writes: >>> Sounds like having to track two separately moving targets. >> >> In fact, I'm only tracking changes introduced in Emacs. But not those >> introduced after my last merge for a specific file (these will have to >> be manually re-checked). >> >> Changes in the cedet trunk should be automatically merged when I merge >> the branch. >> >> >>> Any idea how to make the respective developers aware of the problem >>> and move in a more synchronized fashion, so as to decrease the speed >>> with which the task you have focused on grows? >> >> There's no easy solution. >> >> On one hand, files in Emacs where introduced with modification wrt the >> cedet CVS, so some of them are hard to track. >> >> On the other hand, people won't be able to contribute all the fixes into >> cedet instead of emacs and expect emacs tu pull from cedet; not until I >> finish the file-rename branch. >> >> All this, added with my lack of elisp skill, knowledge on cedet >> internals and knowledge on what has been changed and why, make the task >> a tough one. > > Let's assume that you get the task completed in the manner you envision > and you are working on right now, and the merge and synch happens as > planned. > > Will that leave Cedet and Emacs in a state where future synchronizations > of Cedet to Emacs will be possible in a semi-automatic manner, like Gnus > is synchronized frequently right now? > > Or will it mean that every future synchronization will require just as > much effort as your current work? > > In short: if you manage to catch up with your target, will it be > reasonably easy to keep it from running off again? > I'm not that familiar with bzr, but the idea is that once this conversion is done, merges could be automated on some way, except for conflicts. My dream is some sort of cron job that merges from Emacs back into a CEDET integration branch, and also from the CEDET trunk into the integration branch, and warns when a merge fails. When Emacs wants to sync back, the merge would be quite simple from the integration branch at any time. Periodically, someone could merge the Emacs integration branch into CEDET trunk. The challenge is just finding someone with the right skills and time to help out. Eric