Rewriting Ubuntu branches
James Westby
jw+debian at jameswestby.net
Thu Dec 17 22:56:22 GMT 2009
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
More information about the ubuntu-distributed-devel
mailing list