When working in a source controlled workspace, the PB generated PBG files serve role of mapping of source files to specific PBLs. They are the lynch pin in SCC operation
I am thoroughly convinced that PBG files (caused by the way they are managed by the PB/SCC process) are not trustworthy. Risk is inversely relative to PBG integrity
Imagine this scenario (Which recently occurred):
- Using VS Team Explorer (TFS) DeveloperA moves 3 code objects from SA\SA.PBL (source) to CommonB\CommonB.PBL (target). sHe then edits both PBG files to reflect the change and checks in the changeset. DeveloperA notifies fellow developers by sending an eMail requesting 2 GLV operations (get latest version) one on the source PBL; one on the target PBL. Following the 2 GLVs fellow developers will see 3 new code objects in their target PBL under SCC with history intact and three code objects in the source PBL not under SCC, which they are instructed to delete.
- However, DeveloperB, BEFORE doing the GLV requested by DeveloperA, adds 2 new code objects to CommonB.PBL and checks in her change.
a. .SRD source for 2 files is exported
b. 2 .SRD files are added
c. Change is checked in
d. PBG file is ‘checked out’
e. Local PBG file is generated based on local PBL contents, getting 2 new listings and removing 3 listings added by developer A
f. PBG is updated
g. PBG file is checked in and no longer contains listing for code objects added by DeveloperA
- Developer C does GLV on CommonB and gets 2 code objects (Not 5!)
a. PBG is CORRUPT! It no longer properly represents proper PBL contents
b. This developer’s CommonB.PBL is corrupt!
c. Any developers who GLV afterwards will not get new all new code objects
To anyone in the community in a PB multi-developer source controlled environment: What is your strategy for ensuring local developer source integrity? How do you synchronize source code changes around your team?
PS: Doing the move using TFS tools preserves change history. Remove from SCC/delete/add from within PB loses change history