When deployed or certified by Perforce Consulting, the core functionality of the SDP is officially supported by Perforce Support, except for files in the Unsupported directory tree.
The Unsupported folder included with the SDP is community supported, but officially supported by Perforce Support. (Unsupported files were in various folders prior to the 2020.1 release.)
The SDP is open source software (see the LICENSE), and accepts contributions (pending code review) from the user community.
The Server Deployment Package (SDP) is the implementation of Perforce's recommendations for operating and managing a production Perforce Helix Core Version Control System.
The SDP provides a set of management scripts for operating various Perforce Helix Core topology components, such as:
For p4d in particular, the SDP provides an implementation of best practices suited for production environments, such as performing daily offline checkpoints with zero downtime, rotating logs and journals routinely. The SDP provides optimized init scripts that do database sanity/safety check before starting the server. Init scripts support both SysV and systemd init mechanisms.
The SDP supports a variety of methods for achieving high availability that benefit simple, single-server environments and sophisticated global enterprise environments, and all in between. Standardized and documented recovery procedures, offline databases, and optional replication (made easier with the SDP) all make HA easier to achieve.
Just as with HA, the SDP makes it easier to implement robust, reliable DR strategies.
The SDP makes upgrades of Helix server products fast and easy, regardless of the scale of your environment. By taking advantage of the offline database structure, the SDP enables upgrades with just a few minutes of downtime (enough to do a journal rotation).
The p4d executable, without any configuration, is optimized for evaluation and demonstration purposes. While it has many features that can make it reliable and robust, many of those features must be configured. The SDP is intended to be used for production environments or more realistic Proof of Concept installations.
See the Helix Installer which makes quick work of installing the SDP for PoC evaluation with a production-like setup, complete with the Sample Depot training data set.
The SDP also maintains, on an ongoing basis, a set of best-practices configuration settings (e.g. 'configurables' and environment settings) suited to production environments, which often differ from p4d defaults.
The SDP provides a standard structure for operating Perforce that is optimized for performance, scalability, and ease of backup. The SDP Guide includes documentation that promotes volume layout and storage architecture best practices.
To simplify backup, all digital assets are in a single directory. Live databases that cannot be backed up live in another, and active log files in another. For any scale environment, this makes it easy to back up the server's critical data. For larger scale environments, these directories become storage volume mount points, with the layout promoting best performance and data safety.
In addition to the basics, the SDP provides structure, standards, guidance, and automation that greatly simplify deployment and management of sophisticated Helix global topologies. For example, the SDP includes tools that greatly simplify complex tasks such as creating new replicas, backing up edge servers without down time, etc.
The SDP supports operation of multiple instances of Helix on a machine, allowing each instance to have differing configuration, e.g. different:
The SDP provides standard mechanism for defining a controlled shell environment. This benefits p4d and other Perforce software products directly, and also provides good examples of controlling the environment for supporting automation.
The SDP defines a standard for installing and configuring derived APIs. For example, Python is built with P4Python in /p4/common/python, and Perl with P4Perl in /p4/common/perl.
Many Perforce customers use the SDP as-is. Others benefit by incorporating concepts and ideas from the SDP into their own environments, e.g. for development of custom policy enforcement triggers, systems integrations, promoting or enforcing local naming conventions, etc.
The Helix Management System (HMS) is a separate, community-supported product that builds on the SDP. This is likely to be of interest at installations with sophisticated global topologies and/or a fleet of SDP instances to manage.
Perforce Jobs are used to file bugs and request enhancements to the SDP. The list of jobs (other than closed ones) can be viewed here.
You can see all jobs (including closed ones if desired) from the command line interface. Connect to The Workshop and run the <code>p4 jobs</code> command, something like this:
p4 jobs -l -e "Project=perforce-software-sdp ^Status=closed"While there is currently no formal roadmap for the SDP, it is actively maintained and continues to evolve alongside P4D and other Helix Core components it manages. Jobs are occasionally reviewed and addressed as time allows for consultants and contributors, sometimes driven by customer-funded consulting projects.
Contributions to the SDP are most welcome! Note that contributing requires a basic user knowledge of working with Perforce.
For contributing small changes, contribute by shelving changelists to the 'dev' branch your workspace.
All registered Workshop users have open access (but not write) to the SDP dev branch. This allows shelving (but not submitting) updates to the SDP dev branch path:
//guest/perforce_software/sdp/dev/...To contribute by shelving, create a workspace that maps that path, named something like 'your_user.your_hostname.sdp'. Make your changes in that workspace, provide a good changelist description, and include a <code>#review</code> tag in your changelist description.
When you are ready, shelve the changelist. Perforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.
Optionally, you may also branch the SDP dev branch, 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 like this:
Branch: your_name-sdp
Owner: your_name
Description:
SDP Updates by your_name.
Options: unlocked
View:
//guest/perforce_software/sdp/dev/.. //guest/your_name/sdp/dev/...If you branch a subset, maintain the full path structure (as in the example above), so you can easily expand the scope of what you branched initially at some later date.
Edit, test and submit changes in your branch. Keep your code up to date with other changes by merging down from the shared dev branch to your dev branch, e.g. by doing:
p4 merge -b your_name-sdp... followed by the usual resolve and submit.
When you'e ready to copy your versions up to our dev branch, do like so:
p4 change
p4 copy -c YourCL -r -b your_name-sdpBe sure that your changelist has a clear and accurate description, and that the description contains a <code>#review</code> tag on a line by itself. That will trigger a code review process when you shelve the change, like so:
p4 shelve -c YourCLPerforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.
You may want to version the SDP locally. See the SDP Guide for basic versioning instructions.
Optionally, sophisticated enterprise installations may want to use the "Tight Ship" style of management, to be in line with the "Version Everything" mindset. For more info, see the Helix Management System (HMS).
If you have an earlier version of the Server Deployment Package (SDP) installed and are not using Tight Ship style of management, you'll want to be aware of the <code>-test</code> flag to the SDP setup script, <code>mkdirs.sh</code>. The following update instructions assume a simple, single-server topology. (For older SDP installations, this path may be <code>/depotdata/sdp</code>.)
Get the new software from The Workshop, which you'll find in the form of a SDP.Unix.*.tgz zipped tar file. Put the tar file in the <code>/hxdepots</code> folder on your server. BE SURE TO MOVE THE OLD <code>/hxdepots/sdp</code> folder aside first if it is there, e.g. to <code>/hxdepots/sdp.old.2014-10-08</code>.
Then unpack it like this:
tar -xzvpf SDP.Unix.2017.5.####.tgz
cd /hxdepots/sdp/Unix/setupModify the mkdirs.sh script to suit your environment (possibly borrowing values from your old <code>mkdirs.sh</code> script).
Then run it:
mkdirs.sh 1 -testThat'll do a mock install, creating a <code>/tmp/p4</code> structure, with folders like <code>/tmp/p4/common/bin</code> and <code>/tmp/p4/1/bin</code>. The output will suggest some <code>diff -r</code> commands to run to to view the diffs and apply updates manually, being careful not to lose any customizations or local configuration changes you may have made.
If the SDP itself is versioned in Perforce in your environment, you can also put the new things from /tmp/p4 into your Perforce server where the SDP is. Commonly, there is a branch for receiving pristine updates of the generic SDP, e.g. 'p4c', which allow you to use Perforce merging to merge update into your local SDP mainline.
Contact Perforce Consulting Services to ask about engaging professional services to upgrade the SDP for you.
A few quick things to be aware of:
The old <code>p4_1_init</code> script (more generically <code>p4_instance_init</code>) was renamed to <code>p4d_1_init</code>. This will require updates to init script or symlink, e.g. in <code>/etc/init.d</code>.
Once you upgrade p4d to 2014.1+, you can do away with the SDP trigger that updates depot spec map fields. You can clear the <code>Map:</code> fields of depots, and use the <code>server.depot.root</code> configurable. Going forward, you'd only use <code>Map:</code> fields for depots that really do require a unique path, e.g. archive depots.
The SDP structure enables two major views of a Perforce server, the system administrator/storage architect view, and the application administrator view. THe system admin sees this structure:
/hxdepots
/hxmetadata1
/hxmetadata2
/hxlogsSystem administrators know they need to backup <code>/hxdepots</code>. Backing up <code>/hxlogs</code> is optional, and /hxmetadata1 & /hxmetadata2 are to be avoided by backup utilities, virus scanners, and anything else that might touch files in that area. This view is designed for optimizing for performance, as each of those folders has different performance profiles and usage patterns demanded by p4d. This view is not concerned with how many instances there are, or how they vary.
Application administrators (Perforce Admins), though a structure of symlinks, see Perforce from a view like this:
/p4/1/bin
/p4/1/depots
/p4/1/checkpoints
/p4/1/root
/p4/1/offline_db
/p4/1/tmp
/p4/common/config
/p4/common/bin
/p4/ssl
This structure illustrates an instance named '1' (it need not be numeric), and a /p4/common area containing files common to all instances. Each of those folders is physically stored under an appropriate storage folder or volume as defined in the system admin view above.
The <code>/p4/instance/bin</code> folder defines which Perforce products are active for that instance on the current machine (p4d, p4broker, p4p, etc.). The root folder contains P4ROOT, while depots contains archive files.
There are two flavors of the SDP, Unix and Windows. Both are available from the SDP downloads folder.
An automated regression test suite and pre-commit code review processes help ensure code quality. This is supplemented by manual testing in the Battle School training lab environment. Contact Perforce Consulting for more information.
See more details about the test suite in the Test Suite README file.
What is the Server Deployment Package (SDP)?
===
Supported Open Source Software
---
*When deployed or certified by Perforce Consulting*, the core functionality of the SDP is officially supported by Perforce Support, except for files in the `Unsupported` directory tree.
The `Unsupported` folder included with the SDP is community supported, but officially supported by Perforce Support. (Unsupported files were in various folders prior to the 2020.1 release.)
The SDP is open source software (see the [LICENSE](https://swarm.workshop.perforce.com/projects/perforce-software-sdp/files/main/LICENSE)), and accepts contributions (pending code review) from the user community.
Overview
---
The Server Deployment Package (SDP) is the implementation of Perforce's recommendations for operating and managing a production Perforce Helix Core Version Control System.
Simplified Management
---
The SDP provides a set of management scripts for operating various Perforce Helix Core topology components, such as:
* **p4d** - Helix Core Version Control System, including master/commit servers, replicas, and edge servers.
* **p4broker** - A topology component of Helix Core
* **p4p** - Perforce Helix Proxy
* **p4dtg** - Perforce Defect Tracking Gateway
* and others ...
For **p4d** in particular, the SDP provides an implementation of best practices suited for production environments, such as performing daily _offline checkpoints_ **with zero downtime**, rotating logs and journals routinely. The SDP provides optimized init scripts that do database sanity/safety check before starting the server. Init scripts support both SysV and systemd init mechanisms.
High Availability (HA)
---
The SDP supports a variety of methods for achieving high availability that benefit simple, single-server environments and sophisticated global enterprise environments, and all in between. Standardized and documented recovery procedures, offline databases, and optional replication (made easier with the SDP) all make HA easier to achieve.
Disaster Recovery (DR)
---
Just as with HA, the SDP makes it easier to implement robust, reliable DR strategies.
Fast and Safe Upgrades
---
The SDP makes upgrades of Helix server products fast and easy, regardless of the scale of your environment. By taking advantage of the offline database structure, the SDP enables upgrades with just a few minutes of downtime (enough to do a journal rotation).
Production Focus
---
The p4d executable, without any configuration, is optimized for evaluation and demonstration purposes. While it has many features that can make it reliable and robust, many of those features must be configured. The SDP is intended to be used for production environments or more realistic Proof of Concept installations.
See the [Helix Installer](https://swarm.workshop.perforce.com/projects/perforce_software-helix-installer) which makes quick work of installing the SDP for PoC evaluation with a production-like setup, complete with the Sample Depot training data set.
Best Practice Configurables
---
The SDP also maintains, on an ongoing basis, a set of best-practices configuration settings (e.g. 'configurables' and environment settings) suited to production environments, which often differ from p4d defaults.
Optimal Performance, Data Safety, and Simplified Backup
---
The SDP provides a standard structure for operating Perforce that is optimized for performance, scalability, and ease of backup. The SDP Guide includes documentation that promotes volume layout and storage architecture best practices.
To simplify backup, all digital assets are in a single directory. Live databases that cannot be backed up live in another, and active log files in another. For any scale environment, this makes it easy to back up the server's critical data. For larger scale environments, these directories become storage volume mount points, with the layout promoting best performance and data safety.
Sophistication Simplified
---
In addition to the basics, the SDP provides structure, standards, guidance, and automation that greatly simplify deployment and management of sophisticated Helix global topologies. For example, the SDP includes tools that greatly simplify complex tasks such as creating new replicas, backing up edge servers without down time, etc.
Multi-Instance Management
---
The SDP supports operation of multiple instances of Helix on a machine, allowing each instance to have differing configuration, e.g. different:
* versions of software components (p4d, p4broker, etc.)
* case sensitivity setting (sensitive/insensitive)
* Unicode setting (enabled/disabled)
Shell Environment Management
---
The SDP provides standard mechanism for defining a controlled shell environment. This benefits p4d and other Perforce software products directly, and also provides good examples of controlling the environment for supporting automation.
Perforce Automation Standards
---
The SDP defines a standard for installing and configuring derived APIs. For example, Python is built with P4Python in /p4/common/python, and Perl with P4Perl in /p4/common/perl.
Stock vs. Custom SDP
---
Many Perforce customers use the SDP as-is. Others benefit by incorporating concepts and ideas from the SDP into their own environments, e.g. for development of custom policy enforcement triggers, systems integrations, promoting or enforcing local naming conventions, etc.
Helix Management System
---
The [Helix Management System (HMS)](https://swarm.workshop.perforce.com/projects/perforce_software-hms) is a separate, community-supported product that builds on the SDP. This is likely to be of interest at installations with sophisticated global topologies and/or a fleet of SDP instances to manage.
Bugs, Enhancements, and Future Plans
===
Perforce Jobs are used to file bugs and request enhancements to the SDP. The list of jobs (other than closed ones) can be viewed [here](https://swarm.workshop.perforce.com/projects/perforce-software-sdp/jobs "SDP Open Jobs").
You can see all jobs (including closed ones if desired) from the command line interface. Connect to The Workshop and run the <code>p4 jobs</code> command, something like this:
```
p4 jobs -l -e "Project=perforce-software-sdp ^Status=closed"
```
While there is currently no formal roadmap for the SDP, it is actively maintained and continues to evolve alongside P4D and other Helix Core components it manages. Jobs are occasionally reviewed and addressed as time allows for consultants and contributors, sometimes driven by customer-funded consulting projects.
Contributing
===
Contributions to the SDP are most welcome! Note that contributing requires a basic user knowledge of working with Perforce.
Contributing by Shelving (Small Changes)
---
For contributing small changes, contribute by shelving changelists to the 'dev' branch your workspace.
All registered Workshop users have **open** access (but not **write**) to the SDP dev branch. This allows shelving (but not submitting) updates to the SDP dev branch path:
```
//guest/perforce_software/sdp/dev/...
```
To contribute by shelving, create a workspace that maps that path, named something like '*your_user*.*your_hostname*.sdp'. Make your changes in that workspace, provide a good changelist description, and include a <code>#review</code> tag in your changelist description.
When you are ready, shelve the changelist. Perforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.
Contributing by Branching (Bigger Changes)
---
Optionally, you may also branch the SDP dev branch, 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 like this:
```
Branch: your_name-sdp
Owner: your_name
Description:
SDP Updates by your_name.
Options: unlocked
View:
//guest/perforce_software/sdp/dev/.. //guest/your_name/sdp/dev/...
```
If you branch a subset, maintain the full path structure (as in the example above), so you can easily expand the scope of what you branched initially at some later date.
Edit, test and submit changes in your branch. Keep your code up to date with other changes by merging down from the shared dev branch to your dev branch, e.g. by doing:
```
p4 merge -b your_name-sdp
```
... followed by the usual resolve and submit.
When you'e ready to copy your versions up to our dev branch, do like so:
```
p4 change
p4 copy -c YourCL -r -b your_name-sdp
```
Be sure that your changelist has a clear and accurate description, and that the description contains a <code>#review</code> tag on a line by itself. That will trigger a code review process when you shelve the change, like so:
```
p4 shelve -c YourCL
```
Perforce Consultants will review the change, and either incorporate it or provide feedback. Be sure to provide a detailed change description, and don't forget include the <code>#review</code> tag in your changelist description to initiate a Swarm pre-commit code review.
Guidelines for SDP Contributors
---
* Communicate! Use Swarm or email! Let folks know what you're planning before you work too hard on something that might already be underway.
* File a job (Project=**perforce-software-sdp**) first. That's not required, but increases the transparency of what you're doing, and helps promote it.
* We prefer changes that are generic, and have a wide appeal.
* The core of the SDP, the scripts that do offline checkpoints for p4d, prioritize Perforce best practices over scripting magic. Don't get too fancy! :)
Versioning the SDP Locally
===
You may want to version the SDP locally. See the SDP Guide for basic versioning instructions.
Optionally, sophisticated enterprise installations may want to use the "Tight Ship" style of management, to be in line with the "Version Everything" mindset. For more info, see the [Helix Management System (HMS)](https://swarm.workshop.perforce.com/projects/perforce_software-hms).
Upgrading Older Existing SDP Installations
===
If you have an earlier version of the Server Deployment Package (SDP) installed and are *not* using Tight Ship style of management, you'll want to be aware of the <code>-test</code> flag to the SDP setup script, <code>mkdirs.sh</code>. The following update instructions assume a simple, single-server topology. (For older SDP installations, this path may be <code>/depotdata/sdp</code>.)
Get the new software from The Workshop, which you'll find in the form of a SDP.Unix.\*.tgz zipped tar file. Put the tar file in the <code>/hxdepots</code> folder on your server. **BE SURE TO MOVE THE OLD** <code>/hxdepots/sdp</code> folder aside first if it is there, e.g. to <code>/hxdepots/sdp.old.2014-10-08</code>.
Then unpack it like this:
```
tar -xzvpf SDP.Unix.2017.5.####.tgz
cd /hxdepots/sdp/Unix/setup
```
Modify the mkdirs.sh script to suit your environment (possibly borrowing values from your old <code>mkdirs.sh</code> script).
Then run it:
mkdirs.sh 1 -test
That'll do a mock install, creating a <code>**/tmp/**p4</code> structure, with folders like <code>/tmp/p4/common/bin</code> and <code>/tmp/p4/1/bin</code>. The output will suggest some <code>diff -r</code> commands to run to to view the diffs and apply updates manually, being careful not to lose any customizations or local configuration changes you may have made.
If the SDP itself is versioned in Perforce in your environment, you can also put the new things from /tmp/p4 into your Perforce server where the SDP is. Commonly, there is a branch for receiving pristine updates of the generic SDP, e.g. 'p4c', which allow you to use Perforce merging to merge update into your local SDP mainline.
Contact [Perforce Consulting Services](mailto:consulting@perforce.com) to ask about engaging professional services to upgrade the SDP for you.
A few quick things to be aware of:
* The old <code>p4_1_init</code> script (more generically <code>p4_instance_init</code>) was renamed to <code>p4**d**_1_init</code>. This will require updates to init script or symlink, e.g. in <code>/etc/init.d</code>.
* Once you upgrade p4d to 2014.1+, you can do away with the SDP trigger that updates depot spec map fields. You can clear the <code>Map:</code> fields of depots, and use the <code>server.depot.root</code> configurable. Going forward, you'd only use <code>Map:</code> fields for depots that really do require a unique path, e.g. archive depots.
SDP Structure
===
The SDP structure enables two major views of a Perforce server, the system administrator/storage architect view, and the application administrator view. THe system admin sees this structure:
/hxdepots
/hxmetadata1
/hxmetadata2
/hxlogs
System administrators know they need to backup <code>/hxdepots</code>. Backing up <code>/hxlogs</code> is optional, and /hxmetadata1 & /hxmetadata2 are to be avoided by backup utilities, virus scanners, and anything else that might touch files in that area. This view is designed for optimizing for performance, as each of those folders has different performance profiles and usage patterns demanded by p4d. This view is not concerned with how many instances there are, or how they vary.
Application administrators (Perforce Admins), though a structure of symlinks, see Perforce from a view like this:
```
/p4/1/bin
/p4/1/depots
/p4/1/checkpoints
/p4/1/root
/p4/1/offline_db
/p4/1/tmp
/p4/common/config
/p4/common/bin
/p4/ssl
```
This structure illustrates an instance named '1' (it need not be numeric), and a /p4/common area containing files common to all instances. Each of those folders is physically stored under an appropriate storage folder or volume as defined in the system admin view above.
The <code>/p4/*instance*/bin</code> folder defines which Perforce products are active for that instance on the current machine (p4d, p4broker, p4p, etc.). The **root** folder contains P4ROOT, while **depots** contains archive files.
The Windows SDP
===
There are two flavors of the SDP, Unix and Windows. Both are available from the [SDP downloads folder](https://swarm.workshop.perforce.com/projects/perforce-software-sdp/files/downloads).
SDP Code Quality
===
An automated regression test suite and pre-commit code review processes help ensure code quality. This is supplemented by manual testing in the Battle School training lab environment. Contact [Perforce Consulting](mailto:consulting@perforce.com) for more information.
See more details about the test suite in the [Test Suite README file](https://swarm.workshop.perforce.com/projects/perforce-software-sdp/files/main/test/README.md).
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #30 | 31208 | C. Thomas Tyler | Merged down hot patch to web docs only (no functional change). | ||
| #29 | 30395 | C. Thomas Tyler | Merge down README.md fix. | ||
| #28 | 30379 | C. Thomas Tyler |
Updated README.md for 2024.1 release. Removed the generated README.html file due to issues with rendered HTML format. The automated rendering via Helix Swarm is rather nice. |
||
| #27 | 30000 | C. Thomas Tyler |
Refined Release Notes and top-level README.md file in preparation for coming 2023.2 release. Adjusted Makefile in doc directory to also generate top-level README.html from top-level README.md file so that the HTML file is reliably updated in the SDP release process. Updated :revnumber: and :revdate: docs in AsciiDoc files to indicate that the are still current. Avoiding regen of ReleaseNotes.pdf binary file since that will need at least one more update before shipping SDP 2023.2. |
||
| #26 | 29963 | C. Thomas Tyler | Merge down from main. | ||
| #25 | 29932 | C. Thomas Tyler |
Merge down @29916 from main: Removed mention of Helix Installer while we resolve issues around inexperienced users managing to zap their existing repository. #review-29933 |
||
| #24 | 29915 | Robert Cowham | Remove reference to Helix Installer for now. | ||
| #23 | 28861 | C. Thomas Tyler | Merged patch to README.md. | ||
| #22 | 28852 | C. Thomas Tyler |
Release notes corrections and tweaks to SDP home page related to the major version change.. |
||
| #21 | 28385 | C. Thomas Tyler |
Updated README for coming r21.2 release. Enhanced product description to emphazise key SDP benefits, better describing the value of the Offline DB. #review-28386 |
||
| #20 | 27482 | C. Thomas Tyler |
README.md updates: * Added Documentation References section, with less clutter and easier links to PDF/HTML versions of key docs, including the upgrade guide. * Enhanced "Sophistication Simplified" section. * Simplified Support status text. * General grammer corrections. * Removed a broken link. * Simpflified Contribing sections. * Enhanced formatting/TOC levels, moved several sections under new "Features and Benefits" section. #review-27483 |
||
| #19 | 27444 | C. Thomas Tyler | Fixed issue with broken doc links. | ||
| #18 | 27015 | C. Thomas Tyler |
Replaced notes in README.md re: upgrading SDP with ref to new SDP Upgrade Guide doc. The doc URL references not-yet-existing SDP r20.1 branch. |
||
| #17 | 26781 | Robert Cowham | Reference new docs. | ||
| #16 | 26652 | Robert Cowham |
This is Tom's change: Introduced new 'Unsupported' directory to clarify that some files in the SDP are not officially supported. These files are samples for illustration, to provide examples, or are deprecated but not yet ready for removal from the package. The Maintenance and many SDP triggers have been moved under here, along with other SDP scripts and triggers. Added comments to p4_vars indicating that it should not be edited directly. Added reference to an optional site_global_vars file that, if it exists, will be sourced to provide global user settings without needing to edit p4_vars. As an exception to the refactoring, the totalusers.py Maintenance script will be moved to indicate that it is supported. Removed settings to support long-sunset P4Web from supported structure. Structure under new .../Unsupported folder is: Samples/bin Sample scripts. Samples/triggers Sample trigger scripts. Samples/triggers/tests Sample trigger script tests. Samples/broker Sample broker filter scripts. Deprecated/triggers Deprecated triggers. To Do in a subsequent change: Make corresponding doc changes. |
||
| #15 | 26595 | C. Thomas Tyler | Minor updates to README.md, WIP. | ||
| #14 | 25591 | C. Thomas Tyler |
Clarified that Maintenance folder scripts are samples and are NOT officially supported. Updated references to HMS now that it has been split back out into a separate product. |
||
| #13 | 25155 | Robert Cowham | Refer to test/README.md | ||
| #12 | 25043 | C. Thomas Tyler |
Prepared patch SDP/MultiArch/2018.1/23583.p2 Changes: * In README, moved 'Supported Open Source Software' section to the top of the page, to make Support position more visible. * Copyright updated to 2019. * Cleanup of excess script recreate_db_sync_replica.sh * Re-removal of previously deleted script recreate_db_checkpoint.sh, and corresponding removal from test suite. * This patch tarball will also contain some Docker test suite updates already staged in main. By-passing review to trigger an automated test. |
||
| #11 | 24511 | C. Thomas Tyler |
Fixed an obvious doc typo in README files. Bypassing code review. |
||
| #10 | 23353 | C. Thomas Tyler | Fixed typo/grammatical error. | ||
| #9 | 23315 | C. Thomas Tyler |
Overhauled SDP README page to better convey its value, and much more strongly promote the SDP. This also documents the the nature of offical Perforce Support for the SDP, and the limitations of that Support to core SDP functionality. |
||
| #8 | 16784 | C. Thomas Tyler |
Routine Merge Down to dev from main using: p4 -s merge -n -b perforce_software-sdp-dev |
||
| #7 | 15797 | C. Thomas Tyler | Routine Merge Down to dev from main for SDP. | ||
| #6 | 13729 | C. Thomas Tyler | Tweaked formatting on README.md. | ||
| #5 | 12028 | C. Thomas Tyler | Refreshed SDP dev branch, merging down from main. | ||
| #4 | 11535 | Russell C. Jackson (Rusty) | Updated dev from main. | ||
| #3 | 11463 | Russell C. Jackson (Rusty) | Updated dev to prepare for Summit agreed changes. | ||
| #2 | 11038 | Robert Cowham | Catchup from Main | ||
| #1 | 10638 | C. Thomas Tyler | Populate perforce_software-sdp-dev. | ||
| //guest/perforce_software/sdp/main/README.md | |||||
| #1 | 10611 | C. Thomas Tyler | Added README file for the SDP in The Workshop. | ||