When you bootstrapped your development environment (see getting source), you selected a project. Your development environment views that project at the latest revision and views the dependencies at specific revisions in the past.
If you want to switch to working on a different project, either to get the source code for higher projects in your source tree or to see lower projects at more recent revisions, you have two choices:
fx set-petal <project> command. This command edits the jiri metadata for your source tree to refer to the new project and prints instructions for how to actually get the source and build the newly configured project.Fuchsia is divided into a number of projects. Each project views the previous projects at pinned revisions, which means changes that land in one project are not immediately visible to the upper projects.
When making a change that spans projects, you need to think about when the different projects will see the different parts of you change. For example, suppose you want to change an interface in Zircon and affects clients in Garnet. When you land your change in Zircon, people building Garnet will not see your change immediately. Instead, they will start seeing your change once Garnet updates its revision pin for Zircon.
This section outlines how to make the breaking changes mentioned above.
D. For example, D might be Zircon, and P might be Garnet.The preferred way to make changes that span multiple projects is to use a soft transition. In a soft transition, you make a change to D in such a way that the interface supports both old and new clients. For example, if you are replacing a function, you might add the new version and turn the old function into a wrapper for the new function.
Use the following steps to land a soft transition:
D that introduces the new interface without breaking the old interface used by P.D to roll into the integration repository.P to use the new interface.P to roll into the integration repository.D to remove the old interface.For some changes, creating a soft transition can be difficult or impossible. For those changes, you can make a hard transition. In a hard transition, you make a breaking change to D and update P manually.
Note that to prevent accidental clobbering of the manifest contents, Gerrit is configured to not automatically rebase changes that edit a manifest file. You must manually rebase before merging so that your submit is a pure fast-forward.
Making a hard transition is more stressful than making a soft transition because your change will be preventing other changes in ‘D’ from becoming available in dependent projects between steps 1 and 2.
Only Google developers can make hard transitions. See internal documentation for instructions.