From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jim Meyering Newsgroups: gmane.emacs.devel Subject: Re: emacs.git mirror status Date: Fri, 14 Sep 2007 10:57:39 +0200 Message-ID: <87myvpmxoc.fsf@rho.meyering.net> References: <87y7f9n06z.fsf@rho.meyering.net> <87sl5hmz2t.fsf@rho.meyering.net> <86zlzpr663.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189760336 25325 80.91.229.12 (14 Sep 2007 08:58:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 Sep 2007 08:58:56 +0000 (UTC) Cc: Emacs development discussions To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 14 10:58:54 2007 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.50) id 1IW70n-00025B-96 for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2007 10:58:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IW70m-0005BH-J2 for ged-emacs-devel@m.gmane.org; Fri, 14 Sep 2007 04:58:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IW6zh-0004Ua-2T for emacs-devel@gnu.org; Fri, 14 Sep 2007 04:57:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IW6zf-0004T5-Uc for emacs-devel@gnu.org; Fri, 14 Sep 2007 04:57:44 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IW6zf-0004Sk-LM for emacs-devel@gnu.org; Fri, 14 Sep 2007 04:57:43 -0400 Original-Received: from smtp3-g19.free.fr ([212.27.42.29]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IW6zc-0000ql-7H; Fri, 14 Sep 2007 04:57:40 -0400 Original-Received: from smtp3-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp3-g19.free.fr (Postfix) with ESMTP id 9DFB25A22F; Fri, 14 Sep 2007 10:57:39 +0200 (CEST) Original-Received: from mx.meyering.net (mx.meyering.net [82.230.74.64]) by smtp3-g19.free.fr (Postfix) with ESMTP id 849DB5A244; Fri, 14 Sep 2007 10:57:39 +0200 (CEST) Original-Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id 2BD9E384AF; Fri, 14 Sep 2007 10:57:39 +0200 (CEST) In-Reply-To: <86zlzpr663.fsf@lola.quinscape.zz> (David Kastrup's message of "Fri\, 14 Sep 2007 10\:40\:36 +0200") Original-Lines: 48 X-Detected-Kernel: Linux 2.4-2.6 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:78852 Archived-At: David Kastrup wrote: > Jim Meyering writes: >> dhruva wrote: >>> On 9/14/07, Jim Meyering wrote: >>>> You can check out a copy of the repository like this: >>> >>> I have been using it for sometime and hooked to it. Thank you all the >>> efforts you have put in to get Emacs on GIT. GIT supports a CVS server >>> enabling CVS clients to access the GIT repository. Could this be a >>> possible transition plan. >> >> Yes, it is possible. >> However, currently I would not want to allow commit access >> through the git cvsserver emulation. IMHO, it is not mature enough. >> >> Within the next few days, I expect to set up for (read-only) cvs pserver >> access to the gnulib git mirror. If that goes well, we'll soon switch >> primary upstream development from cvs to git. >> >> If all goes well there, it should be easy to do the same for emacs. > > I am afraid that this is not feasible in the current state of affairs: > as long as all multi-tty material in the current trunk is only tracked > and blamed to a point where Miles was synching rather than the > original checkin, one can't seriously work with it. Presumably the > information loss is not yet there in the arch repository from Miles, > so one needs to either make cvsps understand the arch information > present in CVS ChangeLog entries, or import from arch rather than CVS. Too bad. I hope someone has the time to work on that. I don't. > Of course I am aware that the CVS workflow already _is_ hampered by > the information loss, too, but since CVS is rather bad at handling > such information anyway, it might not be as apparent. It's very apparent to me :-) Just compare the git summary of a project that makes a point of having one commit per change set (e.g., git itself) and emacs. The fact that every change comes with a separate commit to ChangeLog that often has no commit log entry means that cvsps does not aggregate that commit with the change to which it applies. However, if the ChangeLog commit were done with the same log entry as all other changes in a change set (ideally, all in the same commit), then tools like cvsps would be able to reconstruct the change set. Ideally, someone would take the time to adapt cvsps or a similar tool to use a heuristic to aggregate a ChangeLog delta -- perhaps by looking at the diff -- with a nearby change set even though their log messages don't match.