Date: Wed, 24 Feb 1999 17:09:16 -0500 Message-Id: <9902242209.AA05977@tantalum> From: "Geoffrey M. Clemm" <email@example.com> To: Bradley.Sergeant@merant.com Cc: firstname.lastname@example.org In-Reply-To: <9901249198.AA919897271@SMTPGwy.MERANT.com> Subject: Re: Some configuration management scenarios From: Bradley.Sergeant@merant.com Ok, now I see how your scenario 3 will work. We don't need P1R1, it only serves to indicate a change in the P1 project's RSR to run off a fixed configuration rather than a latest label. Make sense? Yes, exactly. Also, if we remove the #2 buildin selection rule in workspaces and rely on the RSR rule then my other concerns go away and things get simpler. Great! Thanks for clearing this up. Here's what I've currently got for the amended CM scenario list: ----------------------- (1) There is a project, P1, that produces a series of configurations (there is an identified workspace, Workspace-P1, that produces new configurations for P1). There can only be one checkout of a versioned-resource at any time, and each developer wants to see the same resources, including working-resources, as every other developer (every developer uses Workspace-P1). (2) There is a project, P1, that produces a series of configurations. Each developer on the P1 project wants to work on his activity in isolation (in a personal workspace), and will merge the completed activity into the project (into Workspace-P1) when it is ready to be seen by the other developers. (2.1) New activities must be based on the current state of the project (the contents of Workspace-P1). (2.1-B) A branch-based system is used. All P1 developers are required to work on the same branch (the DAV:branch property of all P1 activities are set to be "branch-P1"). This ensures that only a single branch exists for all versioned resources, and requires a "merge" before CHECKIN for any resources that have been checked-out in parallel. (2.2) New activities must be based on the most recent configuration of P1 (the most recent configuration produced by Workspace-P1), rather than the current state of P1. (2.3) To minimize merge conflicts when merging into Workspace-P1, a developer merges the latest configuration from Workspace-P1 into his personal workspace before merging his activity into Workspace-P1. (3) At some point project P1 produces a configuration C1. Project P2 is now started, based on C1. A workspace, Workspace-P2, is created to generate the series of configurations for P2, and Workspace-P1 is renamed Workspace-P1-C1. An activity is either done for the P1-C1 project (performed in or merged into Workspace-P1-C1) or for the P2 project (performed in or merged into Workspace-P2). (3.1) Any bug-fix activities for P1-C1 should be incorporated into the P2 project (be merged into Workspace-P2). (3.1-B) A branch-based system is used. All P1 activities have their DAV:branch property set to branch-main. After P1 produces a particular configuration, C1 (e.g. corresponding to a product release), a new project, P2, is started based on C1. All P2 activities have their DAV:branch property set to branch-main, and all P1 activities now have their DAV:secondary-branch property set to branch-P1. The effect of the DAV:secondary-branch is that this branch is used when a revision is checked out that already has a branch-main successor. Then when a P1 activity is merged into Workspace-P2, only versioned resources that have a branch-P1 branch need to be merged (the others were effectively automatically merged on checkin).