From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Switching CEDET from CVS to a Distributed VCS. Date: Tue, 30 Jun 2009 08:19:54 +0900 Message-ID: <874otyy6ed.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1245882173.24086.14.camel@projectile.siege-engine.com> <87r5x8xl04.fsf@uwakimon.sk.tsukuba.ac.jp> <7024025A-9919-46C4-A06E-7878E2116A78@gmail.com> <87k52wyj9k.fsf@uwakimon.sk.tsukuba.ac.jp> <6314DBFC-0104-4EFC-8CFE-B023E929C9B9@gmail.com> <877hywxxn6.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1246317636 16645 80.91.229.12 (29 Jun 2009 23:20:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Jun 2009 23:20:36 +0000 (UTC) Cc: Emacs-Devel devel To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 30 01:20:29 2009 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 1MLQ9F-00059x-5U for ged-emacs-devel@m.gmane.org; Tue, 30 Jun 2009 01:20:29 +0200 Original-Received: from localhost ([127.0.0.1]:49142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLQ9E-00055b-7w for ged-emacs-devel@m.gmane.org; Mon, 29 Jun 2009 19:20:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLQ8r-000546-Et for emacs-devel@gnu.org; Mon, 29 Jun 2009 19:20:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLQ8l-00053K-Kx for emacs-devel@gnu.org; Mon, 29 Jun 2009 19:20:04 -0400 Original-Received: from [199.232.76.173] (port=49606 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLQ8l-00053G-Eg for emacs-devel@gnu.org; Mon, 29 Jun 2009 19:19:59 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:43592) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MLQ8k-0001Vq-L5 for emacs-devel@gnu.org; Mon, 29 Jun 2009 19:19:59 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id DA49E8214; Tue, 30 Jun 2009 08:19:48 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 669EE12827C; Tue, 30 Jun 2009 08:19:54 +0900 (JST) In-Reply-To: X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 5bbff3553494 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:111819 Archived-At: David Reitter writes: > On Jun 28, 2009, at 10:04 AM, Stephen J. Turnbull wrote: > > This would be an amazing time sink for the Savannah people, is my > > guess. Not a good idea -- a lot of people would use it and conflicts > > would be frequent, I think. > > Point well taken. Still, Savannah already has an excellent git mirror. I suppose they could keep it running pretty cheaply. IMO it's mission creep, and Savannah doesn't need mission creep, they have enough trouble just staying up. > I was hoping that all that will remain outsourced, as it is now. I've > had plenty of bad experiences with importing (CVS mostly) into bzr; Simply importing CVS is horrible because commits are non-atomic and lack much necessary metadata to reconstruct commits and branching events reliably. Experience with CVS doesn't even extrapolate to SVN, let alone bzr, git, and hg. > > Trying to maintain bidirectional synchronization is going > > to drive somebody crazy. > > For this reason I was wondering if the patch-bundle route would be a > clean way to push stuff to bzr. No. Why do you think it would be any better than anything else? Once you've got atomic commits, the rest of the issues are "what metadata does your VCS record?" which are pretty similar for the VCSes under consideration, and genuine conflicts, which have to be resolved somewhere. VCSes aren't magic; when you and I make different changes to the same line of code, some human has to sort that out. The problem with bidirectional mirrors is that humans are "supposed" to be out of the loop at the point where genuine conflict occurs. Unidirectional mirrors don't face this problem, and with a local bidi mirror, responsibility for the problem is clear and equal to the person who will experience damage/inconvenience.