Re: Bazaar migration status?

[Ken Raeburn]

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