This is the home of the Perforce Baseline & Branch Import tool, P4BBI.
The P4BBI tool supports the migration strategy mentioned in the blog article,
Baseline and Branch Import (BBI) - A Migration Strategy. This strategy has been used by many companies over the years to quickly migrate from any number of legacy SCM systems to Perforce.
The BBI approach is "front door" to Perforce. "Front door" means that it accesses Perforce using the same interface that a human user would, such as the command line interface or published APIs (like P4Perl, P4Python, P4PHP, P4Ruby, P4Java, the C++ API, etc.). This particular tool uses only the 'p4' command line only.
A key benefit of a front door approach is that it can be operated against a live, running Perforce server, without needing downtime. Another benefit is that no special permissions are required; only write access to target depot paths is needed (depending on features used; some requrie super user access). Typically dry runs are performed into a stand-alone test server for verification purposes, and final imports are done into a live server.
This version of the P4BBI tool tested with P4D 2015.2 servers. It should work with older and newer versions as well, with some known exceptions:
If you just want the latest released version of the file, it is in the Perforce server here:
https://swarm.workshop.perforce.com/projects/perforce_software-p4bbi/files/dist/p4bbi.tgz
Please contact Perforce Consulting (mailto:Consulting@Perforce.com) for more information.
===
All registered Workshop users have open access (but not write) to the P4BBI project, specifically to these paths:
//guest/perforce_software/p4bbi/dev/...
The open access level confers the ability to edit and shelve changes for a pre-commit review process. We'll review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and also include the tag/text "<CODE>#review</CODE>" in your changelist description before you shelve it, in order to initiate a Swarm code review. (If you forget, just modify your changelist description to add the <CODE>#review</CODE> tag, and then force-shelve it again).
Contributing by shelving is ideal if you changes are relatively small in scope, and if they're more solid than experimental.
Optionally, you may also branch the p4bbi folder, or some subset of it, into your own guest area. Creating a branch spec is recommended for this purpose, e.g. with a branch spec something like this:
Branch: your_name-p4bbi
Owner: your_name
Description:
P4BBI Updates by your_name.
Options: unlocked
View:
//guest/perforce_software/p4bbi/main/... //guest/your_name/p4bbi/main/...
Edit, test and submit changes in your branch. Then when you are done, send us an email [consulting@perforce.com](mailto:consulting@perforce.com?subject=BBI Pull Request) which servers as a pull request, and tell us what you'd like us to know about your change.
Contributing by branching is a better option of your changes are larger in scope, or more experimental in nature.
Communicate using this Swarm page! Follow this project, comment on features, and let folks know what you're planning before you work hard on something that might already be underway. Or take your own crack at it!
Review the list of non-closed jobs. Or you can get that from the command line:
<code>p4 jobs -l -e "Project=perforce_software-p4bbi ^Status=closed"</code>
File bugs or feature requests. Use the 'p4 job' command, setting Project=perforce_software-p4bbi, and also set Type field to Feature or Bug.
Filing a job is not strictly required, but increases the transparency of what you're doing, and helps promote it.
Generic changes with a wide appeal are more likely to get implemented.
Perforce Baseline and Branch Import (P4BBI) === Welcome --- This is the home of the Perforce Baseline & Branch Import tool, P4BBI. Introduction --- The P4BBI tool supports the migration strategy mentioned in the blog article, [Baseline and Branch Import (BBI) - A Migration Strategy](http://www.perforce.com/blog/090804/baseline-branch-import-bbi-migration-strategy). This strategy has been used by many companies over the years to quickly migrate from any number of legacy SCM systems to Perforce. Going Through The Front Door --- The BBI approach is "front door" to Perforce. "Front door" means that it accesses Perforce using the same interface that a human user would, such as the command line interface or published APIs (like P4Perl, P4Python, P4PHP, P4Ruby, P4Java, the C++ API, etc.). This particular tool uses only the 'p4' command line only. A key benefit of a front door approach is that it can be operated against a live, running Perforce server, without needing downtime. Another benefit is that no special permissions are required; only write access to target depot paths is needed (depending on features used; some requrie super user access). Typically dry runs are performed into a stand-alone test server for verification purposes, and final imports are done into a live server. P4D Compatibility --- This version of the P4BBI tool tested with P4D 2015.2 servers. It should work with older and newer versions as well, with some known exceptions: * Use of the RENAME action in BBI config files requires P4D 2009.1+ * Use of Streams features requires at least P4D 2011.1, but may may require newer versions depending on stream specs used. If you just want the latest released version of the file, it is in the Perforce server here: [https://swarm.workshop.perforce.com/projects/perforce_software-p4bbi/files/dist/p4bbi.tgz](https://swarm.workshop.perforce.com/projects/perforce_software-p4bbi/files/dist/p4bbi.tgz) Contact Us --- Please contact Perforce Consulting (mailto:Consulting@Perforce.com) for more information. === Contributing by Shelving --- All registered Workshop users have **open** access (but not **write**) to the P4BBI project, specifically to these paths: //guest/perforce_software/p4bbi/dev/... The **open** access level confers the ability to edit and **shelve** changes for a pre-commit review process. We'll review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and also include the tag/text "<CODE>#review</CODE>" in your changelist description before you shelve it, in order to initiate a Swarm code review. (If you forget, just modify your changelist description to add the <CODE>#review</CODE> tag, and then force-shelve it again). Contributing by shelving is ideal if you changes are relatively small in scope, and if they're more solid than experimental. Contributing by Branching --- Optionally, you may also branch the p4bbi folder, or some subset of it, into your own guest area. Creating a branch spec is recommended for this purpose, e.g. with a branch spec something like this: Branch: your_name-p4bbi Owner: your_name Description: P4BBI Updates by your_name. Options: unlocked View: //guest/perforce_software/p4bbi/main/... //guest/your_name/p4bbi/main/... Edit, test and submit changes in your branch. Then when you are done, send us an email [consulting@perforce.com](mailto:consulting@perforce.com?subject=BBI Pull Request) which servers as a pull request, and tell us what you'd like us to know about your change. Contributing by branching is a better option of your changes are larger in scope, or more experimental in nature. Guidelines for P4BBI Contributors --- * Communicate using [this Swarm page](https://swarm.workshop.perforce.com/projects/perforce_software-p4bbi)! Follow this project, comment on features, and let folks know what you're planning before you work hard on something that might already be underway. Or take your own crack at it! * Review the [list of non-closed jobs](https://swarm.workshop.perforce.com/projects/perforce_software-p4bbi/jobs). Or you can get that from the command line: <code>p4 jobs -l -e "Project=perforce_software-p4bbi ^Status=closed"</code> * File bugs or feature requests. Use the 'p4 job' command, setting **Project=perforce_software-p4bbi**, and also set Type field to **Feature** or **Bug**. * Filing a job is not strictly required, but increases the transparency of what you're doing, and helps promote it. * Generic changes with a wide appeal are more likely to get implemented.
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#6 | 18506 | C. Thomas Tyler | Released P4BBI/MultiArch/2016.2/18504 (2016/03/04). | ||
#5 | 18412 | C. Thomas Tyler | Released P4BBI. | ||
#4 | 15968 | C. Thomas Tyler |
Copy Up to main from dev using: p4 copy -r -b perforce-software-p4bbi-dev |
||
#3 | 12395 | C. Thomas Tyler |
Copy Up to main for release. Updated ditribution tar file. |
||
#2 | 11782 | C. Thomas Tyler | Corrected minor copy/paste typo. | ||
#1 | 11584 | C. Thomas Tyler | Added README for P4BBI. |