In I82848367bd6f191ec5ae5822a1f438070cde14e1 we avoided spawning
merge jobs for non-live items.
In Id533772f35ebbc76910398e0e0fa50a3abfceb52 we backed that out
partially by spawning merge jobs for non-live items if they update
the config (so we can create a layout).
In I38925e5fd0ed5ff45aab17d108740345716fd478 we accepted that in
the case of non-live items in a bundle that updated config, we
would spawn multiple merge jobs and each one should be responsible
for updating its own item.
However, we can revisit the assumptions in
Id533772f35ebbc76910398e0e0fa50a3abfceb52 which appears not to have
taken bundles into consideration.
A bundle should have the same files results for every item in the
bundle, so, channeling the original spirit of
I82848367bd6f191ec5ae5822a1f438070cde14e1, we can try to avoid
spawning merge jobs for multiple items in a bundle. This is an
alternate solution to the issue addressed by
I38925e5fd0ed5ff45aab17d108740345716fd478 in that rather than
accepting that we will receive multiple merge jobs in the case of
a bundle with non-live items that each update config, we will instead
receive only one merge job for the entire bundle regardless of
whether they update config, or even whether they are live.
This is accomplished by establishing a single "bundle item" for
the bundle which is defined as the first live item in the bundle.
This is the only item in the bundle that will spawn merge jobs.
When the merge job for that item completes, all of the items in
the bundle will be updated with the results.
Change-Id: Icfe1f2a126eb13349b510107a305c6eef7b622fb
James E. Blair
2436c1a5df