bzr/LP issues from work discussed at UDS

Andrew Bennetts andrew.bennetts at canonical.com
Thu Dec 10 02:05:44 GMT 2009


James Westby wrote:
[...]
> 1) Merging unrelated branches in a recipe.
> 
[...]
> One way to alleviate the pressure on this issue would be to make it possible
> to combine lp:<project> and lp:ubuntu/<package>, even though they are not
> mergeable.
> 
> https://code.edge.launchpad.net/~spiv/bzr-builder/merge-subdirs-479705/+merge/14979
> is said to go some way towards doing this, but as I say within, I think
> I am missing something, as it can't be the whole solution on its own.

I've added a comment on that merge review; you're right that as is it
doesn't provide this, but it's quite close I think.

[...]
> 6) Guessing parent relationships
> 
> We currently infer parent relationships from debian/changelog, as
> if you include changelog entries of another upload then we presume
> you merged the changes.
> 
> We will need to start inferring parent relationships in some cases
> though, as there are some uses that means the code that was uploaded
> is never exactly committed as a single revision. (Such as never
> commiting the revision that changes the target from UNRELEASED
> to unstable, or files modified in the clean target.)
> 
> The heuristics shouldn't have to be too fuzzy, but any fuzziness
> makes me a little nervous, do the bzr developers agree? Do you
> have any advice on how to do it well, so that it doesn't cause
> mis-merges and the like?

I share your nervousness, but I don't have any ideas about what to do
about it yet.  But I don't really understand what sort of fuzziness
you're envisaging, or what exactly you do with the inferred parent
relationships (are they recorded as revision parents to be stored in the
revision graph indefinitely?).

Can you elaborate more on this?

> 7) Migration over branch history rewrites
[...]
> There's obviously a lot of risk in this, and also a whole
> lot of code needed to do this well. Jelmer said that
> bzr-rewrite(?) already contains some code to do something like
> this, so we will be able to start from there.

Jelmer strikes me as a good person to discuss this with.  And yes, I
believe bzr-rewrite is the name of that plugin.

> Here I'm looking for advice on how to do this well, and also
> things like how to distribute the maps and where to put the code
> to do the work. I'm also very keen on any suggestions you
> may have for doing this in a way that avoids these issues.
> 
> Also, we have a terrible user experience on the flag day:
> 
>   # day before
>   $ bzr pull
>   ...
>   # flag day
>   $ bzr pull
>   bzr: ERROR: there is no common ancestor.
> 
> any suggestions on how to improve on that would be gratefully
> received.

Maybe something really crude would be good enough here?  e.g. the
bzr-builddeb plugin could decorate the builtin cmd_pull and if
NoCommonAncestor occurs check if the parent has some special flag set
(e.g. in its branch.conf), and if so report that.  The branch.conf could
even have a string to display to the user when this happens.

That's not a great answer because that doesn't deal with 'bzr merge' or
other commands, but maybe there's something cheap-but-adequate like that
we can do.

-Andrew.




More information about the ubuntu-distributed-devel mailing list