Comment 5 for bug 605059

On 14/07/10 17:41, Loïc Minier wrote:
> Yes, bzr merge is the way to do it; if by "incremental merge" you
> mean keep all revisions, that's exactly what will happen -- just like
> for the merges we're doing when we merge topic branches (with
> multiple commits) into gcc-linaro with bzr merge.

OK, that would be my preference.

> I think we need to be careful of the points at which we merge. We
> could merge continuously, at random points, that's probably ok but
> makes life complex for downstreams like Ubuntu which will then apply
> our diff on top on a released tarball, possibly after applying an SVN
> update patch.

I don't see how?

> e.g. for Ubuntu it's either: - we merge random revisions, Ubuntu
> takes the diff between latest FSF release we have merged and our
> latest release; things go well if Ubuntu is basing on the same FSF
> release, but the SVN diff can't be combined with ours; if Ubuntu uses
> newer or older FSF base, things might not apply - we merge at precise
> FSF release points; it's as above, except SVN diff is likely to be
> applicable

Ubuntu should diff our release against the baseline they intend to apply
it to. If they diff against anything else, then things will break -
they'd be doing it wrong!

Whether the 4.4.x elements are at the start of our history, at the end,
in the middle, or scattered throughout is irrelevant - once it's been
flattened into a release tarball, it all looks the same, and a diff
upstream will just skip over any and all bits in both.

> Another way to avoid the issue would be for the Ubuntu update process
> to be a bit more complex, taking a SVN checkout + FSF tarball +
> Linaro tarball as inputs instead of creating the SVN diff and the
> Linaro diff independently.

Again, it doesn't matter how a source tree is assembled, the Linaro diff
needs to be created against the tree it will be applied to, be that a
plain vanilla FSF release, or a conglomeration of patches.

> So I'd rather have us follow FSF release points for now and discuss
> how to handle that with Ubuntu at the next occasion.

Upgrading one FSF release at a time suits me. Those are the snapshots
they test, and problem revisions will have been fixed or reverted. I'd
suggest we'd need a good reason to do anything else.

> I think the way to merge all revisions up to 4.4.5 is, from a
> gcc-linaro 4.4 checkout or a topic branch based on it: bzr merge -r
> tag:gcc_4_4_5_release lp:gcc/4.4

So, you intend to collapse the entire 4.4.4 -> 4.4.5 history into a
single commit, and then use "bzr log --include-merges" if you want to
unpick it? I thought you said multiple commits?

Andrew