# The form data below was edited by tom_tyler # A Perforce Branch Specification. # # Branch: The branch name. # Update: The date this specification was last modified. # Access: The date of the last 'integrate' using this branch. # Owner: The user who created this branch. # Description: A short description of the branch (optional). # Options: Branch update options: [un]locked. # View: Lines to map source depot files to target depot files. # # Use 'p4 help branch' to see more about branch views. Branch: SDP_Classic_to_Streams Update: 2025/05/11 08:26:12 Access: 2025/04/05 11:39:20 Owner: tom_tyler Description: This branch spec is to be used for migrating SDP from Classic paths to Streams, to be done for SDP r25.1. Currently an empty //sdp stream depot exists and is used only for workspace management - it has no files. It uses 'import+' in the Paths field of the stream spec paths to reference paths in the legacy Classic structure. To avoid impacting ongoing SDP operations, this //sdp depot will remain empty, and a new //p4-sdp stream depot will be created to be the new physical home of the SDP. The migration strategy allows for extensive testing of the new structure, including impact on URLs, prior to an orchestrated precise point-in-time cutover. While Classic and Streams structures will both exist, only Classic will be allowed to accept "real work" up until the cutover. After that point, the Classic structure will become read-only and locked down to future edits. At the start of this process, the SDP 2024.2 has already been released with some patches. Any subsequent patches for 2024.2 will come from the Classic structure. The SDP 2025.1 release will be the first to come from the new Streams structure and will follow the Streams workflows. == Stream Creation Notes The p4-sdp stream depot and streams were created like so: $ p4 -u super-tom_tyler depot -t stream -o p4-sdp | p4 -u super-tom_tyler depot -i Depot p4-sdp saved. $ p4 stream -t mainline -o //p4-sdp/main | p4 stream -i Stream //p4-sdp/main saved. $ p4 stream -t development -P //p4-sdp/main -o //p4-sdp/dev | p4 stream -i Stream //p4-sdp/dev saved. $ p4 -s populate -b SDP_Classic_to_Streams -s //guest/perforce_software/sdp/...@31368 info: 478 files branched (change 31397) exit: 0 == Stream Structure and Population //p4-sdp/dev - dev branch for new work to evolve. This full dev stream will be the first to be populated in Streams. It will be populated from the latest in the Classic dev branch, plus from the 'tools' folder that, in the Classic world, is parallel to main. Until the cutover to Streams, this branch will have no direct edits; it is reserved for automated merging from the Classic dev branch. Avoiding edits ensures automated merge success for as long as merges are needed, i.e. until the production cutover to Streams. The first changeslist in the Streams dev branch will be from @31368 in the Classic dev branch, representing the SDP 2024.2 Patch 3 release, so that the baseline in the Streams dev branch is a perfect match for a formal SDP release. Subsequently, merges will be done from the Classic dev branch to the Streams dev branch up until the cutover to Streams, to occur sometime before the r25.1 release. //p4-sdp/main - to be populated initally from the dev stream. This will contain no direct edits during the migration, only promotions from the dev stream. This will mirror the Classic main branch in content. Post-cutover, emergency hot fixes can be made directly in release streams. Regression test suite builds will established for the main stream while not yet disabling builds for the Classic main branch. //p4-sdp/dev_c2s - dev stream for work specific to the Classic to Streams migration. For example, this branch will be used to make edits to docs and URLs related to the Streams migration wherever they appear in .adoc, .md, .sh, .py, and other files. Use 'grep' to verify 100% coverage. Among other things, this will affect the top-level README.md file that Swarm displays as the SDP home page after the cutover (though changes will be viewable in the dev branch URL prior to release). Among other changes, the package_downloads.sh script must be updated so it runs in whatever the current stream is (e.g. r25.1, dev, main, etc.) and publishes to that stream's downloads directory. The main stream's downloads directory will be the persistent one targeted by URLs to reflect the latest published SDP (the URL will remain unchanged from Classic, and will be managed by Swarm paths). //p4-sdp/r25.1 - Sparse release stream to be created from //p4-sdp/main shortly before release, as part of the SDP 2025.1 release process. The release will come from this stream, so that all files in the tarball have r25.1 in the paths. == Versioning In parallel with the migration to Streams, the SDP will change the versioning scheme used by scripts and docs in the SDP. This may have some exceptions if it creates undue hardship for certain types of files. The gist is that files will have the +k file type modifier, and will use expanded $Id tags (which include depot paths) as part of the file versioning. In a Streams world, these depot paths will have meaning related to versioning. For example, a path that starts with //p4-sdp/r25.1 clearly was released with the r25.1 version of the SDP. == Preparation The Preparation phase is non-disruptive to current SDP release operations occurring in the Classic structure. == Cutover Procedure Notes * Update Workshop Swarm SDP project 'branches' to reference new Stream paths. * Add and verify Apache redirects so URLs referencing Classic land in Streams. * p4 -s merge -c CL -r -S //p4-sdp/dev This is a big enough project to consider doing a Dry Run, with a sandbox Public Depot server and sandbox Swarm server. This would imply creation of said sandboxes. The Apache redirects are likely to require extensive testing and tweaking. If we don't do a Dry Run, we need to be ready to focus on resolving issues for a solid day or two after cutover. To consider: Do we want a 'p4 copy' vs. starting clean in the //p4-sdp depot with a code drop? Is there enough value in having the connected rev graph of the history vs. the baggage that comes along? == To consider: How to handle the 'downloads' folder. For sure the history of the downloads folder from //guest/perforce_software/sdp/downloads will be left behind. In the new stream depot, we'll create //p4-sdp/main/downloads folder. We'll use 'isolate' in the Paths fields so that each physical stream will have its own independent downloads folder, containing the tarball for that release. This will also allow for easier testing of tarballs on the dev branch. We may want +Sn filetypes for the tarball/zip. We'll craft remote specs that exclude the downloads folder from fetches. (We may also want an optional lightweight remote spec that filters out PDFs, pptx files, etc?) == To consider: Existing fetch consumers Some SDP customers consume SDP updates from The Workhop via a 'p4 fetch', including our own internal p4hms server. See: https://swarm.workshop.perforce.com/files/guest/perforce_software/hms/dev/p4/common/site/hms/doc/SDP_and_HMS_Update_Process.md With this changes, these customers will no longer get updates until some kind of adaptation is done. Adaptation will need to be tested, may involve something like: * Fetch all changes up to r25.1 as per normal. * Change 'origin' remote specs. * Maybe adjust LastFetch artifically (if needed). * Pickup up where they left off. == Web Site Changes: A new p4-sdp project has been added to P4 Code Review to replace the sdp project. Options: unlocked View: //guest/perforce_software/sdp/dev/... //p4-sdp/dev/... //guest/perforce_software/sdp/tools/... //p4-sdp/dev/tools/...