On Tue, 28 Sep 2010 21:39:54 +0200, Vincent Ladeuil <v.ladeuil...@free.fr> 
wrote:
> There is a merge proposal that goes in this direction pending review at:
> https://code.edge.launchpad.net/~vila/bzr/323111-orphan-config-option/+merge/35690
> (with pre-requisites).

Great.

>     > 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
branch.

>     > 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
reverted.

> 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
trunk.

Thanks,

James

-- 
ubuntu-distributed-devel mailing list
ubuntu-distributed-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel

Reply via email to