7 months agosuper-tom_tyler updated project (AutoMerge) Some helpful tooling to automated merges into development streams. Previously described here: http://www.perforce.com/company/newsletter/2009/10/tec...hnofiles-living-edge-automated-merging « | ||
7 months agosuper-tom_tyler updated project (AutoMerge) Some helpful tooling to automated merges into development streams. Previously described here: http://www.perforce.com/company/newsletter/2009/10/tec...hnofiles-living-edge-automated-merging « | ||
4 years agosuper-tom_tyler modified SDP-574 for daily_checkpoint.sh hangs if journalPrefix is wrong. Detail: The truncate_journal() in backup_functions.sh hangs if journalPrefix is misconfigured. ... There is a logic block in truncate_journal that is intended to wait for a 'p4 -p $P4MASTERPORT admin journal' to fully complete processing before the function returns. It does so by waiting for the numbered journal file to appear in the checkpoints folder. This works as intended when the journalPrefix is correct. However, if the journalPrefix is wrong, the wait loop still occurs, causing a hang waiting forever for a journal file that is never going to appear. « | ||
Add a comment | ||
6 years agosuper-tom_tyler commented on review 25741 (monitor_metrics.sh, line 49) for perforce-software-sdp:dev Perhaps compare against template.sh line, which uses: msg "That took $((SECONDS/3600)) hours $((SECONDS%3600/60)) minutes $((SECONDS%60)) seconds.\n" ...Perhaps compare against template.sh line, which uses: msg "That took $((SECONDS/3600)) hours $((SECONDS%3600/60)) minutes $((SECONDS%60)) seconds.\n" If we need base10, we should tweak that in template.sh and other scripts too. Or maybe we only need to ensure base10 if not using the built-in SECONDS variable? « | ||
6 years agosuper-tom_tyler created P4XFER-1 for perforce-software-p4transfer: Add an interactive wizard of some kind to greatly simplify setup of a P4Transfer configuration. It should query the user for a working directory (t...he root of the workspaces and home of the transfer.cfg file), and then query them for details of the source and target servers. It should then ask questions that determine the set of default flags to be used for that configuration (e.g. -k, --ignore, etc.), and somehow persist that information, e.g. perhaps generating a 'P4TransferWrapper.py' wrapper script that just calls P4Transfer.py withose flags. Then the wizard should generate the workspaces to be used with P4Transfer on both the source and target servers. It should login in using the credentials provided (relying on a ticket if no password is specified, just as with normal P4Transfer.py operation). The workspaces should be configured with best practices for a workspace used P4Transfer. By "best practices," it should, for example, determine whether 'noallwrite' or 'allwrite' option and/or the submitunchanged/leaveunchanged option is best for a workspace to be used with P4Transfer. If there is no best practice, just pick one. « | ||
6 years agosuper-tom_tyler created P4XFER-2 for perforce-software-p4transfer: Add an interactive wizard of some kind to greatly simplify setup of a P4Transfer configuration. It should query the user for a working directory (t...he root of the workspaces and home of the transfer.cfg file), and then query them for details of the source and target servers. It should then ask questions that determine the set of default flags to be used for that configuration (e.g. -k, --ignore, etc.), and somehow persist that information, e.g. perhaps generating a 'P4TransferWrapper.py' wrapper script that just calls P4Transfer.py withose flags. Then the wizard should generate the workspaces to be used with P4Transfer on both the source and target servers. It should login in using the credentials provided (relying on a ticket if no password is specified, just as with normal P4Transfer.py operation). The workspaces should be configured with best practices for a workspace used P4Transfer. By "best practices," it should, for example, determine whether 'noallwrite' or 'allwrite' option and/or the submitunchanged/leaveunchanged option is best for a workspace to be used with P4Transfer. If there is no best practice, just pick one. « | ||
7 years agosuper-tom_tyler committed change 23498 into Added license. | ||
7 years agosuper-tom_tyler modified SDP-58 for Take full advantage of systemd features. With job SDP-13, basic systemd support was added to the SDP, enabling SDP to play nice on Linux OS veresion...s where systemd replaces SYS5 init scirpts. However, the goal then was merely to add basic support. This job captures the hope to explore and take full advantage of systemd features to optimum benefit of the SDP. Exatly what should be done requires getting fully up to speed on systemd strengths, features, limitations, etc. See also: SDP-241 « | ||
7 years agosuper-tom_tyler modified SDP-258 for Doing 'source p4_vars 1' hangs if a live checkpoint is running. | ||
8 years agosuper-tom_tyler modified CBD-23 for | ||
8 years agosuper-tom_tyler modified CBD-24 for Enable bi-directional stream-spec/*.cbdsst workflow. Provide a workflow that allows developers to modfiy CBD configurations via traditional stream s...pec edits, or via changes to the *.cbdsst file. A change in either updates the other implicitly via trigger actions. This change will help make CBD automation somewhat more transparent. Implementation Detail: Presently, the CBD trims version specifiers from the versioned form of the stream spec (the *.cbdsst file). This is done for a few reasons: * Earlier versions of P4D didn't support version specifiers in stream specs, so they had to be trimmed off or the server would reject them. P4D 2015.1 supports changelists only as revision specifiers. * CBD supports any valid revision specifier, while P4D 2015.1 supports only changelists. P4D 2015.2 may add support for automatic labels and timestamps. That leaves only static labels (important) and workspaces (not so import) as revision specifiers supported by these CBD scripts outside of P4D. Decision: * CBD automation will detect P4D version: o If P4D < 2014.1, strip all revision specifiers going from *.cbdsst -> live stream spec. o If P4D < 2014.2, strip all revision specifiers going from *.cbdsst -> live stream spec except changelist numbers. o If P4D < 2015.2, strip all revision specifiers going from *.cbdsst -> live stream spec except changelist numbers and automatic labels. Warning: The ability to update stream specs directly had proven a helpful workaround to earlier CBD issues which have since been eliminated. This change would eliminate that flexibility, though it seems it is longer be needed. « | ||
8 years agosuper-tom_tyler modified CBD-31 for Change default sync rev for '...' on a back-in-type sync. Change the default revision used for a 'p4 sync' when a back-in-time sync is done, i.e. a... sync with a revision specifier, thus selecting an older version of the *.cbdsst file (which represents the state of the versioned stream spec at the old revision). Currently, when a back-in-time sync is done, the sync uses the correct specified revisions when they are specified explicitly in the older version of the *.cbdsst file, e.g. a Paths: field containing: import foo/... //foo/main/...@275 However, if no revision is explicilty specified, e.g.: import foo/... //foo/main/... the current behvaior is simply to pass the '...' along to the server, resulting in the head revisions being selected for a sync to files in //foo/main/... With this job, the desired new behvaior is to make it so the implicit default, when no revision is specified, becomes the point specified changelist number. So, if a user does: p4 sync @500 and that results in syncing a //ace/main/ace.cbdsst@500, and in that revision there is a Paths: field containing: import foo/... //foo/main/... then desired behavior is to translate that sync to the equivalent of: p4 sync //foo/main/...@500 == OPTIONAL == For visual optimization, the @500 could be replaced with the latest changelist up to @500 that actually affected files in the path //foo/main..., and so it might actually get translated to something like: p4 sync //foo/main/...@275 assuming @275 is the latest changelist up to @500 that affected files in //foo/main/... In all cases, 'p4 sync' behavior also applies to 'flush' and 'update' commands (which is current behavior). « | ||
8 years agosuper-tom_tyler created CBD-37 for Always On mode not working correctly with StreamDepth>1. Hi Tom, I ran in to another issue. Always On is broken now. Expected result is //...DeepPlayground/DeepShared1/lib1/libs/...@1207340 p4 sync --parallel=0 //DeepPlayground/DeepShared1/lib1/...#head INFO: [CBD sync ['--parallel=0'], 'Path [//DeepPlayground/DeepShared1/lib1/...] is out of CBD scope. Assuming #head.']. //DeepPlayground/DeepShared1/lib1/libs/readme.txt updated C:\Users\mpadmanaban\Perforce\mpadmanaban_WS-2UA2220HRW_main_2801\libs\readme.txt 1 file updated 1 warning reported INFO: [CBD sync ['--parallel=0'], 'Path [//DeepPlayground/DeepShared1/lib1/...] is out of CBD scope. Assuming #head.']. Thanks, - Magesh « | ||
8 years agosuper-tom_tyler modified job000519 for Sync on stream with import fails to pick up import when StreamDepth>1. | ||
8 years agosuper-tom_tyler modified CBD-36 for Sync on stream with import fails to pick up import when StreamDepth>1. | ||
8 years agosuper-tom_tyler modified CBD-36 for Sync on stream with import fails to pick up import when StreamDepth>1. | ||
8 years agosuper-tom_tyler created CBD-35 for Sync above stream root with StreamDepth>1 gives annoying but harmless warnings. p4 sync --parallel=0 //DeepPlayground/Components/...#head INFO: [...CBD sync ['--parallel=0'], 'Path [//DeepPlayground/Components/...] is out of CBD scope. Assuming #head.']. //DeepPlayground/Components/main/DeepPlayground-Components.cbdsst added C:\Users\mpadmanaban\Perforce\mpadmanaban_laptop\DeepPlayground-Components.cbdsst 1 file added 1 warning reported INFO: [CBD sync ['--parallel=0'], 'Path [//DeepPlayground/Components/...] is out of CBD scope. Assuming #head.']. « | ||
8 years agosuper-tom_tyler created CBD-34 for Path collision with deep depots (StreamDepth>1). I think we need to add an error check to make sure that cbd key *_path0 is not modified after be...ing initialized. e.g.: Just for test, I tried the following 2 streams and it confused the cbd script, because there is a collision. //DeepThought/Components/tools_test1_main //DeepThought/Components_tools/test1_main « | ||
8 years agosuper-tom_tyler modified CBD-33 for Paramter to logging module should be filemode rather than mode. | ||
8 years agosuper-tom_tyler modified CBD-33 for Paramter to logging module should be filemode rather than mode. | ||
8 years agosuper-tom_tyler modified CBD-32 for Support StreamDepth > 1. | ||
8 years agosuper-tom_tyler created CBD-32 for Support StreamDepth > 1. | ||
8 years agosuper-tom_tyler created CBD-31 for Change default sync rev for '...' on a back-in-type sync. Change the default revision used for a 'p4 sync' when a back-in-time sync is done, i.e. a... sync with a revision specifier, thus selecting an older version of the *.cbdsst file (which represents the state of the versioned stream spec at the old revision). Currently, when a back-in-time sync is done, the sync uses the correct specified revisions when they are specified explicitly in the older version of the *.cbdsst file, e.g. a Paths: field containing: import foo/... //foo/main/...@275 However, if no revision is explicilty specified, e.g.: import foo/... //foo/main/... the current behvaior is simply to pass the '...' along to the server, resulting in the head revisions being selected for a sync to files in //foo/main/... With this job, the desired new behvaior is to make it so the implicit default, when no revision is specified, becomes the point specified changelist number. So, if a user does: p4 sync @500 and that results in syncing a //ace/main/ace.cbdsst@500, and in that revision there is a Paths: field containing: import foo/... //foo/main/... then desired behavior is to translate that sync to the equivalent of: p4 sync //foo/main/...@500 == OPTIONAL == For visual optimization, the @500 could be replaced with the latest changelist up to @500 that actually affected files in the path //foo/main..., and so it might actually get translated to something like: p4 sync //foo/main/...@275 assuming @275 is the latest changelist up to @500 that affected files in //foo/main/... In all cases, 'p4 sync' behavior also applies to 'flush' and 'update' commands (which is current behavior). « | ||
8 years agosuper-tom_tyler created CBD-30 for | ||
8 years agosuper-tom_tyler created CBD-29 for From Windows clients, if your drive letter is uppercase in Perforce metadta (e.g. 'C:\MyWS'), but your current working directory has a lowercase lett...er (e.g. c:\MyWs'), CBD gives an error when trying to sync: ERROR: CBD was not able to translate path [pb/...] to depot syntax. If your drive letter is lowercase in the metadata, it alwasy works. A case mismatch for the drive letter should not matter. The expected behavior is to simply ignore the case of the drive letter. The comparison for the rest of the path shout remain case sensitive. « | ||
8 years agosuper-tom_tyler created CBD-28 for | ||
8 years agosuper-tom_tyler created CBD-27 for | ||
8 years agosuper-tom_tyler created CBD-26 for Fix ticket issues: Do 'p4 login' if necessary. Presently, the CBD automation presumes it has a valid ticket. Add a 'p4 login -s' ticket... status check, and if it fails, attempt a 'p4 login' using credentails available via a mechanism similer to that used by the SDP to ensure checkpoints run reliably. This check needs to be added to BOTH the update trigger and the broker filter script. This change will increase the coupling betweeen CBD and the SDP, which has been kept to a minimum thus far. That's acceptable. « | ||
8 years agosuper-tom_tyler created CBD-25 for Sync //path/...@Label always gets latest files w/p4d 2015.1. I noticed some discrepancy in Stream sync using Labels with workspace. For example,&n...bsp; When I sync using the command p4 sync //<workspace>/...@<Label>, It always gets the latest code instead of the labelled code. When I try to sync using p4 sync //<workspace>/*@<Label>, I get the correct files at the top level. When I try to sync using p4 sync //<depot_path>/...@<Label>, I get the correct files. Command used: p4 sync //jam/...@LABEL <-always gets the latest files p4 sync //jam/*@LABEL <- works p4 sync //jam//main/...@LABEL <- works « | ||
8 years agosuper-tom_tyler created CBD-24 for Enable bi-directional stream-spec/*.cbdsst workflow. Provide a workflow that allows developers to modfiy CBD configurations via traditional stream s...pec edits, or via changes to the *.cbdsst file. A change in either updates the other implicitly via trigger actions. This change will help make CBD automation somewhat more transparent. Implementation Detail: Presently, the CBD trims version specifiers from the versioned form of the stream spec (the *.cbdsst file). This is done for a few reasons: * Earlier versions of P4D didn't support version specifiers in stream specs, so they had to be trimmed off or the server would reject them. P4D 2015.1 supports changelists only as revision specifiers. * CBD supports any valid revision specifier, while P4D 2015.1 supports only changelists. P4D 2015.2 may add support for automatic labels and timestamps. That leaves only static labels (important) and workspaces (not so import) as revision specifiers supported by these CBD scripts outside of P4D. Decision: * CBD automation will detect P4D version: o If P4D < 2014.1, strip all revision specifiers going from *.cbdsst -> live stream spec. o If P4D < 2014.2, strip all revision specifiers going from *.cbdsst -> live stream spec except changelist numbers. o If P4D < 2015.2, strip all revision specifiers going from *.cbdsst -> live stream spec except changelist numbers and automatic labels. Warning: The ability to update stream specs directly had proven a helpful workaround to earlier CBD issues which have since been eliminated. This change would eliminate that flexibility, though it seems it is longer be needed. « | ||
8 years agosuper-tom_tyler created CBD-23 for | ||
8 years agosuper-tom_tyler created CBD-22 for | ||
8 years agosuper-tom_tyler created CBD-6-3 for Subtask: Implement CBD REWRITE logic for Classic in Cbd.py. See: https://swarm.workshop.perforce.com/projects/perforce-software-cbd/jobs/job000250 | ||
8 years agosuper-tom_tyler created CBD-6-2 for | ||
8 years agosuper-tom_tyler created CBD-6-1 for Subtask: Develop WSTemplateUpdate trigger. See: https://swarm.workshop.perforce.com/projects/perforce-software-cbd/jobs/job000250 Develop WSTemplat...eUpdate trigger to CBD keys (similar to SSTemplateUpdate), and also update user workspaces based on the updated template (unique to the Classic implementation, as this "comes for free" with Streams). « | ||
8 years agosuper-tom_tyler created CBD-6 for Complete implementation of CBD for Classic. | ||
8 years agosuper-tom_tyler created CBD-3 for Add support for Task streams. At issue: In SSTemplateUpdate.py, the 'p4 describe' output for task streams doesn't list depot files (unless run from... the Stream workspace associated with that task stream). This breaks upon creation of a new Task Stream. It doesn't prevent creation of the Task Stream, but fails to update CBD keys for that task stream. « | ||
8 years agosuper-tom_tyler modified CBD-21 for | ||
8 years agosuper-tom_tyler modified job000248 for | ||
8 years agosuper-tom_tyler modified CBD-21 for | ||
8 years agosuper-tom_tyler created CBD-21 for | ||
8 years agosuper-tom_tyler modified job000247 for | ||
8 years agosuper-tom_tyler modified CBD-20 for | ||
8 years agosuper-tom_tyler modified CBD-20 for | ||
8 years agosuper-tom_tyler created CBD-19 for Support depots with multiple modules. This is a code research and testing task. CBD was originally developed with the assumption of a 1:1 rela...tionship between stream depots and components. This task is to ensure that customers using one stream depot to contain multiple component do not experience any adverse effects with CBD. « | ||
8 years agosuper-tom_tyler modified CBD-18 for Add Windows support for server-side CBD back end. While the broker & trigger back end implementation works with any and all client platforms, it... only works when the back end is Linux. Add support for Windows only environments (and of course do it in a way that doesn't break existing Unix/Linux platform support). « | ||
8 years agosuper-tom_tyler modified CBD-18 for Add Windows support for server-side CBD back end. While the broker & trigger back end implementation works with any and all client platforms, it... only works when the back end is Linux. Add support for Windows only environments (and of course do it in a way that doesn't break existing Unix/Linux platform support). « | ||
8 years agosuper-tom_tyler modified CBD-17 for Version 'Remapped:' and 'Ignored:' fields. The initial CBD implementation updated only the 'Paths:' and 'Description:' fields in the live Stream Spe...c when the versioned form, the *.cbdsst file, was updated. The 'Remapped:' and 'Ignored:' are ignored. That functions as initially designed, based on the "miminally intrusive" philosphy to avoid unnecessary impact of the custom CBD logic. However, later it was deeemd better for all aspects of the stream spec to be dictated by the versioned from of the file if we're going to have one at all, so they can go through the same merge down/copy up flow as Paths updates. « | ||
8 years agosuper-tom_tyler modified job000244 for Version 'Remapped:' and 'Ignored:' fields. The initial CBD implementation updated only the 'Paths:' and 'Description:' fields in the live Stream Spe...c when the versioned form, the *.cbdsst file, was updated. The 'Remapped:' and 'Ignored:' are ignored. That functions as initially designed, based on the "miminally intrusive" philosphy to avoid unnecessary impact of the custom CBD logic. However, later it was deeemd better for all aspects of the stream spec to be dictated by the versioned from of the file if we're going to have one at all, so they can go through the same merge down/copy up flow as Paths updates. « | ||
Adjust when notifications are sent to you about reviews that you're associated with (as an author, reviewer, project member or moderator).