From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Bazaar migration status? Date: Thu, 23 Jul 2009 18:06:28 -0400 Message-ID: References: <87skgvtatv.fsf@stupidchicken.com> <87vdlpi2t9.fsf@canonical.com> <87skgrj8z6.fsf@catnip.gol.com> <4F76137C-0F9C-4181-8C02-F47C0180A9E3@raeburn.org> <871vo8vz2l.fsf@uwakimon.sk.tsukuba.ac.jp> <4CF97BAA-1FED-45A9-BE96-2A6A68294D12@raeburn.org> <87vdljvms6.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248386889 14208 80.91.229.12 (23 Jul 2009 22:08:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jul 2009 22:08:09 +0000 (UTC) Cc: Emacs Development To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 24 00:08:02 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 1MU6SH-0006zk-Cy for ged-emacs-devel@m.gmane.org; Fri, 24 Jul 2009 00:08:01 +0200 Original-Received: from localhost ([127.0.0.1]:43907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU6SG-000144-Qk for ged-emacs-devel@m.gmane.org; Thu, 23 Jul 2009 18:08:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MU6R1-0008Hg-JK for emacs-devel@gnu.org; Thu, 23 Jul 2009 18:06:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MU6Qw-00087p-JE for emacs-devel@gnu.org; Thu, 23 Jul 2009 18:06:42 -0400 Original-Received: from [199.232.76.173] (port=47185 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MU6Qw-00087c-G1 for emacs-devel@gnu.org; Thu, 23 Jul 2009 18:06:38 -0400 Original-Received: from splat.raeburn.org ([69.25.196.39]:41475 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MU6Qo-0003o4-5I for emacs-devel@gnu.org; Thu, 23 Jul 2009 18:06:38 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6NM6SEa005338; Thu, 23 Jul 2009 18:06:28 -0400 (EDT) In-Reply-To: <87vdljvms6.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.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:113067 Archived-At: On Jul 23, 2009, at 04:14, Stephen J. Turnbull wrote: > "Based work on" is the key phrase. If you *know* nobody has done so, > if you know who has done so and coordinate with them, it's no big > deal, and often the best way to proceed because everybody agrees that > the branch should be rebased, it's just a question of coordinating on > *when*. Yeah, and it'll probably be easier than I think in reality, because while my repository is in theory public, I haven't told anyone where it is yet. But I had been planning to, and wanting to do it soon. And distributed development like git (or bzr) supports shouldn't require that you keep track of everyone downstream from you. But between the indefinite timing of the bzr switchover, and the warnings about how bad rebasing can be for anyone downstream, the message I'm hearing sounds a little like "if you publicize your development repo, we will cause you pain." :-) >> anyone downstream of it is forced to manually fix their >> history. This section explains how to do the fix from the >> downstream's point of view. The real fix, however, would be >> to avoid rebasing the upstream in the first place. >> >> This sort of ripple effect requiring manual intervention for everyone >> downstream seems... rude. > > If done without coordination, sure, it's rude. Somebody who's done > the amount of work that Andreas has done to preserve history is > anything but likely to be rude, though. I didn't mean to cast aspersions on anyone working on this. I guess I'm just wishing the tools provided some extra metadata were carried along somewhere that would make it Just Work without me having to track down and sort out where the two versions of history match up. (And likewise for everyone downstream.) After all, it will be in a sense the same repository after the conversion as it was before; tracking it across the switch ideally ought to be trivial and automatic. >> [I]t seems to be that we *do* want the content to be the same, and >> all the history info... but we're going to have a complete new >> version history anyways, because it's how the tools work today. > > Hm? Uh, if the content is the same, then you haven't rebased at all. I'm assuming we want the history as shown by git or bzr to show exactly the same sources, changed in exactly the same way at exactly the same times and by the same people and with the same log messages, as we see now with CVS or git. What I've been hearing is that the result of mirroring the bzr repository into git isn't likely to give the same commit revision ids as we have in the CVS->git mirror. Which suggests to me that either the content or the metadata is going to come out differently in some way, probably because of the differences between tools. (Or maybe the mirroring tools are non-deterministic in some way affecting the output, but I would hope that wouldn't be the case.) If the bzr->git mirror were expected to generate the same hash values for absolutely everything, I wouldn't have anything to be concerned about. > In that case, somebody has deliberately changed the metadata of > history (eg, git-filter-branch). But you can analyze this with the > tools git (uniquely, AFAIK, cf Miles's "Tribute to a VCS" post :-) > provides: [...] > which will find out if there's any commit whose tree is identical to > HEAD's. Note that if this is the case, you probably can find a whole > branch which is identical to HEAD's branch in terms of content. Interesting... that could be the additional data I was asking for above. Thanks! But, the expectation of different revision ids still concerns me -- is that because of minor differences in content, like maybe translating .cvsignore into something else for bzr or loss of some trivial bit of data like file modes, that will cause the trees not to be identical, or differences in commit metadata that just cause the commit ids to be different despite matching file content? Ken