Rewriting Ubuntu branches

[James Westby]

On Tue, 15 Dec 2009 20:13:56 +0100, Jelmer Vernooij <jelmer at samba.org> wrote:
> Hi James,

Hi,

Thanks for the information, this is invaluable.

> Le lundi 14 décembre 2009 à 00:48 +0000, James Westby a écrit : 
> > I wanted to split this out of the large mail so that we could complete
> > a design of how this would work.
> > 
> > Here's my initial proposal based on the feedback from that thread.
> 
> > 2) We ship map files in some known location, package-import.ubuntu.com say.
> >      These contain revision id pairs and file id pairs corresponding to
> >      the old branches and the new branches. Is just listing plain file ids
> >      safe, or do we need (revision id, file id) pairs to do this correctly.
> > 
> >   3) Either bzr-rewrite itself, of something based on the code in there
> >      will be used to rewrite a given branch using the information in the
> >      map files.
> bzr-rewrite's existing rebase-foreign command can do the renames based
> on paths alone, there is no need to have a file id map. I'm not sure
> whether that is sufficient for what you are trying to do, but I suspect
> it is.

It's a "correctness" thing in my eyes, but one where the chance of
a problem arising is small, at least at this stage.

> rebase-foreign works with foreign revision ids (in this case probably
> debian version strings?), and then determines which bzr revision ids are
> pseudonyms based on the foreign revision ids they originate from. 
> 
> > Open questions:
> > 
> >   * Should we bother with file id maps, or just match based on path?
> I don't think there is a risk for confusion between the identity of two
> files with the same path in similar revisions.
> 
> > * Should we put the old revision ids in to revision properties of
> >     the new revisions? This could be the marker for the decorated
> >     commands, and make the map files smaller. It does inflate the
> >     size of the branches for ever though. If we don't, what should
> >     the marker be?
> If you just put the debian version that a revision refers to in a
> revision property, I don't think there would be that much overhead -
> just around 100 bytes per revision I'd estimate. 

We don't have a deterministic debian version -> revision id mapping.
We do have a known revision id -> revision id mapping though. We could
put this in revision properties, or distribute it separately. Either
way it should be easy to teach bzr-rewrite how to deal with it.
 
> > How does this plan sound? Does anyone want to take on a particular part of
> > it?
> I'm happy to answer questions about bzr-rewrite or help add another
> pseudonym mechanism in bzr-rewrite, if you decide to go that route.

Great, thanks.

James