jw+debian at jameswestby.net
Tue Sep 28 21:16:39 BST 2010
On Tue, 28 Sep 2010 21:39:54 +0200, Vincent Ladeuil <v.ladeuil+lp at free.fr> wrote:
> There is a merge proposal that goes in this direction pending review at:
> (with pre-requisites).
> > 4) Remembering the upstream branch.
> > merge-upstream takes an optional upstream branch. Currently there are
> > cases where one person supplies it, but the next doesn't, and that's not
> > ideal, as you get a discontinuity, and there can be extra conflicts in
> > future due to added files.
> Still related to parallel imports ?
It is parallel imports, yes.
> Martin mentioned recently that we could special-case merge to relax the
> conflicts for different file-ids by checking the paths involved. That
> would not solve the parallel import problem but it may help for the
> packaging and upstream branches relationship.
I think so. This is beyond just that problem though, in that it could be
recording a richer ancestry that it will if you forget the upstream
> > Therefore I would like if if, similar to e.g. bzr merge, if you supply a
> > branch once it is remembered and used again.
> That's clearly a case where some config file should be versioned and
> shared even if it needs to be versioned in a specific way (the reference
> to the upstream branch is a live data that doesn't flow in the same way
> than the upstream code or the packaging data (or does it?)).
It's slightly independent, yes. I would put it in
.bzr-builddeb/default.conf, as that is a good start.
> Would you qualify this upstream branch as a data shared by a set of
> branches but for which updates are never reverted ?
I'm not sure I follow this. I could concoct a situation in which it is
> Couldn't you use an ancestry check against the last merged revision ?
That could make sense.
It wouldn't stop partially unrelated things being merged. If you are
merging a release from a stable branch then you don't want to merge
More information about the ubuntu-distributed-devel