CS 350, slide set 11ReadingTypical ProblemsMajor componentsConfig. Mgmt in CS 350Typical plan componentsContents of Configuration Change Request (CCR)Configuration Change BoardContents of Configuration Status Report – TSP versionBaseline steps: TSP versionRCS: UNIX Revision Control System OverviewRCS continuedBasic RCS structureBasic RCS commands "ci" - 1Basic RCS commands "ci" - 2Basic RCS commands "co"Basic RCS commands, "co –l"More infoCS 350, slide set 11M. OverstreetOld Dominion UniversityFall 2005ReadingTSP text, Appendix B: Software Configuration ManagementTypical ProblemsUncontrolled, unreviewed changesCorrupted or unrecoverable source codeMany slight variants of "current" versionFor different OSsFor different hardware/software environmentsFor different customersFor different in-house developers/users•Stable, infrequently changing version for other developers•Most current and changing version of some developersMajor componentsA Software Configuration PlanA system baselineSubmission policyBackup proceduresConfiguration audit procedureTesting facilitiesSpecializedHardwareSupport toolsConfig. Mgmt in CS 350Minimal – no CCRs!, no CSRs! requiredEach group can decide what is appropriate for the groupNext several slides discuss how this this might be doneTypical plan componentsMust depend on size/complexity of projectIssuesSteps in process•Approval decisions•Reduce bureaucratic overhead•Avoid disastersBaseline submissionsAutomated support tools•Simplify manual tasks•Reduce errors; impact of proposed changesWhen are backups done?When are builds done?Contents of Configuration Change Request (CCR)Product/Component IdentificationChange InformationReason for changeChange descriptionImpact of changeStatus & ApprovalsConfiguration Change BoardEvaluate proposed changes to baselined productsContents of Configuration Status Report – TSP versionConfig. Change Process: ActivityCCRs submitted, approved, rejected, deferred, outstanding, reversedConfig. Change Process: StatusVolume under SCM control: pages, Pseudocode lines, LOC—total, LOC—new and changed, Test case LOC, Test material pages, Test results pagesBaseline steps: TSP versionIndividual completes and tests approved changesApproval by quality/process mgrCCB reviews submissions and approves or disapprovesSupport manager retains backups of all baselined itemsTeam members can normally obtain baselined items at any timeDevelopment manager ensures that only baseline products are used in buildsSupport manager produces weekly CSRsRCS: UNIX Revision Control System OverviewFree with UNIX (Linux)Only partial solutionCommercial systems provide many more servicesConsistent with UNIX philosophy: programmers are smarter than software systemsDoes not enforce rulesDesigned to be used by knowledgeable, cooperating programmersThat is, control is voluntary; really easy to “cheat” – and sometimes necessary.RCS continuedWorks with makeMake knows about RCS and will look in for missing source when neededMakes it easy to recover old versions of filesCan see exact changes made to a file, along with date of changes and who made changesAlerts if two people try to change a file at the same time.Basic RCS structureAssumes related source code is in several files in one directoryAssumes the existence of an RCS directory in the source directoryUse "mkdir RCS" to create this directoryTries to reduce size of files by only recording changes madeBasic RCS commands "ci" - 1"ci <filename>" to remove file from current directory and put a version under RCS controlThis is "checking in" a file to RCSA structured version of the file, along with some documentation, is placed in the RCS directory called <filename>,vYou can edit this file. Don't.Basic RCS commands "ci" - 2When you check a file in:RCS checks to see if you really made changes•No reason to keep two identical versionsRCS prompts you to document your changes•But doesn't force it.RCS assigns a version number (by adding 1 to the old number) so that you can recover exactly this version in the future.Basic RCS commands "co"If a file has been checked in, it can later be "checked out" with the "co" command.co <filename>Everything that can be checked out will be a file in the RCS directoryIf I forget filenames, I often start with•ls –l RCSUse of "ci" means that you promise not to change the file, but just need to read itFor, say, compilation of your component with baselined versions of other componentsYou can edit the file anyway. Don't.Basic RCS commands, "co –l"Unlike use of "co", "co –l" (for "lock") is used when a programmer intends to modify a file.co –l <filename>The file is then "locked."If another team member uses "co –l" for the same file, he/she will get a message that the file is already checked out.UNIX assumes that if you really need it, you will contact the person who checked it out and make some arrangements.You can easily edit the file anyway (this is UNIX). But you should now know that what you're doing may be dangerous.More infoman rcsintro or rcs or co or ci or ident or rcsclean or rcsdiff or rcsmerge or rlog or
View Full Document
Unlocking...