The Perforce integrate command is used to branch new files from existing files, and to propagate changes between branched files. You can also use integrate to effectively rename files by branching new ones from existing ones and deleting the existing ones. Integrate opens target files in your workspace so you can branch or resolve changes from donor files into them.
When used to branch new files, donor file content is copied from the depot into new target files in your workspace. When you submit the target files, they are created in the depot.
When you use integrate to propagate changes between existing files, you will have to resolve the target files before you can submit them to account for changes in the donor files. It's a good idea to sync the target files in your workspace first so that you are working with the head revisions. Otherwise you end up doing two resolves on each file, once to resolve the integrated changes and once to resolve the synced changes.
P4Web lets you run integrate the following ways:
The following advanced options are common to all Integrate pages:
- Limit revision range
- Perforce keeps track of which revisions of a donor file have already been integrated to a target file. Normally integrate opens the target if any donor revisions have not yet been integrated. You can restrict which donor files revisions will be considered by entering a revision range here.
- You can use symbolic revision numbers (e.g.,"@12345") or absolute revision numbers (e.g., "#45").
- If you enter a "starting with" revision, no donor revisions prior to it will be considered. If you don't supply the "@" or "#" prefix, "@" will be assumed.
- If you enter an "ending with" revision, no donor revisions higher than it will be considered. If you don't supply the "@" or "#" prefix, it is assumed to be the same type of revision number as the starting revision you supplied, or "@" if you didn't supply a starting revision.
- Put open files in changelist
- If your client workspace has more than one pending changelist you can select one of them here. The files opened by the integrate command will be put in the pending changelist you select.
- Enable baseless merges
- Normally Perforce only opens a target file for integrate if it can find a common base between it and the donor file to use as a base for doing a merge. A target file and donor file not directly related to each other by branching have no common base; by default the target will not be opened in this case. You can use the "enable baseless merges" option to force target files to be opened even if they are not related to donor files by branching. If you do this, Perforce arbitrarily choses the #1 revision of the donor files to use as a merge base.
- Permit deletes/re-adds
- If the ending revision of the donor file is a deleted file, Perforce normally opens the target file for delete unless the target file has any revisions that have not themselves been integrated to the donor file. If the donor file exists and the target file does not, Perforce normally opens the target file for branch/add unless the target file is a deleted file. Checking the "permit deletes/re-adds" option makes the integrate command open the target file for delete or branch/add even if these conditions exist.
- Force re-integration if previously integrated
- Normally Perforce doesn't open a target file for integrate if all of the donor file revisions under consideration have already been integrated to it. Checking the "force re-integration" option makes the integrate command open the target file for integrate regardless of previous integration history. When you submit the file, integration history between the two files will be effectively rewritten to reflect the most recent of the duplicate integrations.
- Don't copy newly branched files to workspace
- Normally target files opened for branch/add will be created in your workspace. However, since Perforce already knows that the content of the new target files are the same as that of the donor files, your workspace files are not necessary to create the new files in the depot. If you don't need copies of the newly branched files in your workspace -- you are branching a large codeline, for example, but you don't plan to do work in the new codeline yourself -- use this option.