Configuration Management i171k
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 3i3n4
Overview 26281t
& View Configuration Management as PDF for free.
More details 6y5l6z
- Words: 3,273
- Pages: 52
Configuration management
What is CM? • Configuration management (CM) is the discipline of controlling the evolution of complex systems; software configuration management (SCM) is its specialization for computer programs and associated documents. • IEEE standard 729-1983 definition • Identification: an identification scheme reflects the structure of the product, identifies components and their type, making them unique and accessible in some form • "This program worked yesterday. What happened?“ • "I can’t reproduce the error in this configuration.” • "I fixed this problem long ago. Why did it reappear?“ • "The online documentation doesn’t match the program.” • "Do we have the latest version?"
• Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product • "How do I configure a test system that contains my temporary fixes to the last baseline, and the released fixes of all other components?” • "Given a list of fixes and enhancements, how do I configure a system that incorporates them?” • "This enhancement won’t be ready until the next release. How do I configure it out of the current baseline?” • "How exactly does this version differ from the Baseline?" • Status ing: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product. • "Has this problem been fixed?’’ • "Which bug fixes went into this copy?“ • "This seems like an obvious change. Was it tried before?” • "Who is responsible for this modification?” • "Were these independent changes merged?" • Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that the product is a well-defined collection of components
CM in a hardware-development environment • A computer has a processor, a mainboard, some memory, a hard drive, a monitor, and a keyboard. • Each of these hardware items has an interface that connects it to other hardware items. • Your mouse has a plug, and your computer has a port into which you plug your mouse, and makes everything works. • If the plug on the mouse was not compatible with the port on the computer, there would be no way to connect the two pieces of hardware into a working system.
• Throughout the computer, there are many other similar interfaces. • The processor and memory plug into the mainboard, the hard drive plugs into the computer, and the printer, monitor, and keyboard all have interfaces. • When the hardware is manufactured, the interfaces that are essential for the operation of the final system are easily seen. Therefore, they are well known and are carefully examined whenever changes are made to the hardware design. • For a hardware system, configuration management has the following aspects. • Each system is numbered or identified and also has a version number. Each version number identifies different designs of the same part. • When the design of a hardware system is changed, the system gets a new version number.
• A hardware system can be made up of hundreds, thousands, or tens of thousands of parts. • The next thing that must be recorded is which versions of these parts go together. • version of the mouse, hard drive, processor, and monitor go together to make a complete system. • Each of these parts, such as a hard drive, is made of many, many subparts, all of which must go together to have a working unit.
Software development and maintenance phases and CM
Configurati on manageme nt
Documenta tion CM
Code CM
WHY CM? • Software configuration management must ensure that: • software components can be identified; • software is built from a consistent set of components; • software components are available and accessible; • software components never get lost (e.g. after media failure or operator error); • every change to the software is approved and documented; • changes do not get lost (e.g. through simultaneous updates); • it is always possible to go back to a previous version; • a history of changes is kept, so that is always possible to discover who did what and when.
• Software develops from baseline to baseline until it can be released. • Changes to baselines must be controlled throughout the life cycle by documenting the: • problems, so that they can be understood; • changes that are proposed to solve the problem; • modifications that result. • ESA PSS-05-0 identifies five primary configuration management activities: • • • • •
configuration configuration configuration configuration release.
identification; item storage; change control; status ing;
Software Configuration Management Activities (Software configuration management plan)
SPMP – Software project management plan
Important concepts and in CM • Component Item (CI) • A CI is an aggregation of hardware, software or both that is designated as a unit for configuration management, and treated as a single entity in the configuration management process • A CI can be an aggregation of other CIs, organised in a hierarchy. • Any member of this hierarchy can exist in several versions, each being a separate CI.
• Examples of configuration items(CI) are: • software component, such as a version of a source module, object module, executable program or data file; • software item, such as a version of a compiler or a linker; • baseline, such as a software system under development; • release, such as a software system in operational use; • document, such as an ADD.
Types of CI • The type field of a CI identifier should identify the processing the CI is intended for. There are three main types of CI: • · source CIs; • · derived CIs; • · tools to generate derived CIs from source CIs.
Configuration identification • Configuration identification conventions should state how to: • name a CI; • decide who is the control authority of a CI; • describe the history of a CI.
• At the top level, the whole system is a CI. • Several factors may be relevant in deciding what to identify as the lowest level CI, such as the: • software design defined in the ADD and DDD (the lowest level of the software design sets the lowest possible level of configuration management); • capabilities of the software development tools (e.g. the units that the compiler or linkers input and output); • bottom-level work packages defined in the SPMP.
Baselines • A ‘baseline' is a CI that has been formally reviewed and agreed upon (i.e. approved), and declared a basis for further development. • Although any approved CI in a system can be referred to as a baseline, the term is normally used for the complete system. • Early baselines contain only documents specifying the software to be built; later baselines contain the code as well. • The CIs in a baseline must be consistent with each other. Examples of consistency are: • code CIs are compatible with the design document CIs; • design document CIs are compatible with the requirements document CIs; • manual CIs describe the operation of the code CIs.
Variants • The term ‘variant' is often used to identify CIs that, although offering almost identical functionality, differ in aspects such as: • · hardware environment; • · communications protocol; • · language (e.g. English, French).
• Variants may also be made to help diagnose software problems. • The usefulness of such variants is often temporary, and they should be withdrawn when the problem has been solved.
Configuration item control authority • Every CI should have a unique control authority that decides what changes will be made to a CI. • The control authority may be an individual or a group of people. • Three levels of control authority are normally distinguished in a software project: • · software author; • · software project manager; • · review board.
Software author • Software authors create low-level CIs, such as documents and code. • Document writers are usually the control authority for draft documents. • Programmers are normally the control authority for code until unit testing is complete.
Software project manager • Software project managers are responsible for the assembly of high-level CIs (i.e. baselines and releases) from the low-level CIs provided by software authors. • Software project managers are the control authorities for all these CIs. • Low-level CIs are maintained in software libraries. • On most projects the software project manager is ed by a software librarian.
Configuration item history • The development history of each CI must be recorded from the moment it is first submitted for review or integration. • For documents, this history is stored in Document Change Records (DCRs) and Document Status Sheets (DSS). • Change records in module headers should reference the Software Change Request (SCR) that actioned them. • For derived code, the development history is stored in the librarian's database. • The development history should include records of the tests that have been performed. • The Software Modification Report (SMR) should summarise the changes to CIs that have been revised in response to an SCR.
Configuration item storage • All CIs must be stored securely so that they never get lost. • Software projects can accumulate thousands of lowlevel CIs, and just as books are stored in libraries, it is necessary to store low-level CIs in software libraries. • The software libraries are themselves CIs. • Software CIs reside on hardware media (e.g. paper, magnetic disk). • Storage media must be maintained securely and safely so that software is never lost or its integrity compromised.
Software libraries • A software library is a controlled collection of configuration items (e.g. source module, object module and document). • Low-level CIs are developed and stored in libraries (e.g. source and object libraries), and then extracted to build high-level CIs (e.g. executable images). • As a minimum, every project must use the following software libraries to store CIs: • · development (or dynamic) libraries • · master (or controlled) libraries • · archive (or static) libraries
• Master libraries store CIs in the current baselines. • Archive libraries store CIs in releases or retired baselines. • CIs in archive libraries must not be modified
Access control to libraries • Access to software libraries should be controlled so that it is impossible: • · to access CIs without the correct authorisation; • · for two people to simultaneously update the same CI.
• Read access allows a CI to be examined or copied. • Insert access right allows a new CI to be added to a software library. • Delete access right allows a CI to be removed from a library. • Replace right allows a CI to be removed from a library and another version inserted.
Development staff access rights
Software librarian access rights
• Table 1 does not mean that a development library should be accessible to all developers • Apart from the software librarian, only the person directly responsible for developing or maintaining the CIs in a development library should have access to them. For sharing software, master libraries should be used, not development libraries. • Simultaneous update occurs when two or more developers take a copy of a CI and make changes to it. • When a developer returns a modified CI to the master library, modifications made by developers who have returned their CI earlier are lost. • A charge-in/charge-out or ‘locking’ mechanism is required to prevent simultaneous update.
Table 1: Development staff
Media control • All CIs should be stored on controlled media (e.g. tapes, disks). • Media should be labelled, both visibly (e.g. sticky label) and electronically (e.g. tape header). • The label should have a standard format, and must contain the: • • • •
· · · ·
project name configuration item identifier (name, type, version) date of storage content description
• Procedures for the regular backup of development libraries must be established. • Up-to-date security copies of master and archive libraries must always be available . • An aim of good media control is to be able to recover from media loss quickly.
VERSION CONTROL
• Version control • Management of multiple revisions of the same unit of information. • Changes identified by incrementing an associated number or letter code - “revision number”, or “revision level”. • Revision numbers (levels) are associated historically with the person making the change
• Repository • A server where the files are stored.
• Check-Out • copies a working copy from the repository • (the opposite of an import).
• Change • A specific modification to a document under version control. • The granularity of the modification considered a change varies between version control systems.
• Change List
• The set of changes made in a single commit. • A sequential view of the source code.
• Commit or Check-in
• Copy the changes on the local files to the directory. • (the VC software takes care of changes since the last synchronization).
• Update
• copies the changes that were made to the repository into your working directory. • (opposite of a commit).
• Merge / Integration • brings together (merges) concurrent changes into a unified revision.
• Revision or version • one version in a chain of changes.
• Conflict • Occurs when two changes are made by different parties to the same document or place within a document.
• Resolve • The act of intervention to address a conflict between different changes to the same document.
Example CM Clients
Trunk
CM Server Version A Branch
Machine A
Version A.1 Branch
Check Out Check In C
A
Machine B B Check Out D Merg e
E
Check In
Version B Branch
History • CM systems save the files’ history. • Old versions can be viewed, compared, and ed. • New versions can be (irreversibly) replaced with old versions and ‘wiped off the map’.
Central repositories • Files are saved in a central file server. • Developers can view the files in the repository, through the use of filters.
Labels • Several files can be labeled together. • Allows : • Access to the label as a whole set of files. • Changes to the labeled files as a unit.
• Useful for marking product releases.
Check-in • Copies a file into the database. • The version you see is (usually) the latest version that was checked in. • The old version is kept and can be accessed later.
Check out • Copies the database file to your personal folder, and raises a flag on the database copy. • Need to check out before checking in.
Undo check out (uncheck-out) • The “undo checkout” command does just that – the file returns to the status it had before it was checked out. • This can be done even if changes have been made to the local copy – of course, these do not go into the database!
Problems with file sharing • All version control systems have to solve the same fundamental problem: how will the system allow s to share information, but prevent them from accidentally stepping on each other's feet?
Scenario • Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system re every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident.
Versioning Models Lock-Modify-Unlock Solution:
• Only one person can change a file at a time. • Example: VSS. Copy-Modify-Merge Solution:
• s modify private copies only - in parallel • Private copies are merged together into a new, final version. • Example: CVS, Subversion.
The Lock-Modify-Unlock Solution
Problems With Locking • istrative problems: • A can lock a file and forget about it. • Time is wasted while others wait to edit the file.
• Unnecessary serialization: • Different parts of a file don’t necessarily overlap. • E.g.: Alice works on the beginning of a file, Bob wants to edit the end of the same file.
• False sense of security: • Let’s say Alice locks and edits file A, while Bob simultaneously locks and edits file B. • Let’s say A and B depend on one another, and the changes made to each are semantically incompatible. • Suddenly, A and B don't work together anymore.
The Copy-Modify-Merge Solution Aviva and Arik both check out file A. Here, checkout has no locking effect – it’s just a Read local copy. A
Repository A
Read
A
The Copy-Modify-Merge Solution Both edit their local files.
Repository A
Aviva Arik
The Copy-Modify-Merge Solution Aviva checks in her file to the repository first.
Repository Aviva
Write
Aviva
Arik
The Copy-Modify-Merge Solution Now, Arik tries to check-in his file. He gets an “upto-date check error” Write
Arik
Repository Aviva
Aviva
The Copy-Modify-Merge Solution Arik updates his local copy to contain the changes made by Aviva. Changes are added to the local file. During this merge, conflicts may occur.
Read
A’ (=Aviva+Arik )
Repository Aviva
Aviva
The Copy-Modify-Merge Solution A new merged file is created on Arik’s machine.
Repository Aviva
Aviva
B
The Copy-Modify-Merge Solution Arik commits his file to the repository.
Repository B
Write
B
Aviva
The Copy-Modify-Merge Solution Aviva updates her file from the repository.
Repository B
Read
B
B
THE SOFTWARE CONFIGURATION MANAGEMENT PLAN
Introduction • All software configuration management activities shall be documented in the Software Configuration Management Plan • Each SCMP section must document all software configuration management activities, specifically the: • • • • •
· organisation of configuration management; · procedures for configuration identification; · procedures for change control; · procedures for configuration status ing; · tools, techniques and methods for software configuration management; • · procedures for supplier control; • · procedures for the collection and retention of records.
• IEEE Guide to Software Configuration Management contains examples of plans for: • · a complex, critical computer system; • · a small software development project; • · maintaining programs developed by other activities or organisations; • · developing and maintaining embedded software.
• Configuration management procedures must be in place before software production (code and documentation) starts • Software configuration management procedures should be easy to follow and efficient. • Wherever possible, procedures should be reusable in later phases. • Instability in software configuration management procedures can impede progress in a software project.
About SCMP • STYLE • The SCMP should be plain and concise. • The document should be clear, consistent and modifiable. • The author of the SCMP should assume familiarity with the purpose of the software, and not repeat information that is explained in other documents.
• RESPONSIBILITY • The developer is responsible for the production of the SCMP.
• MEDIUM • It is usually assumed that the SCMP is a paper document. • There is no reason why the SCMP should not be distributed electronically to participants with the necessary equipment.
SCMP content
• Reference: • Guide to software configuration management by ESA Board for Software Standardisation and Control (BSSC), ESA PSS-05-09 Issue 1 Revision 1, March 1995 • Software Configuration Management Overview by Walter Tichy • http://svnbook.redbean.com/en/1.0/ch02s02.html
Thank you
What is CM? • Configuration management (CM) is the discipline of controlling the evolution of complex systems; software configuration management (SCM) is its specialization for computer programs and associated documents. • IEEE standard 729-1983 definition • Identification: an identification scheme reflects the structure of the product, identifies components and their type, making them unique and accessible in some form • "This program worked yesterday. What happened?“ • "I can’t reproduce the error in this configuration.” • "I fixed this problem long ago. Why did it reappear?“ • "The online documentation doesn’t match the program.” • "Do we have the latest version?"
• Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product • "How do I configure a test system that contains my temporary fixes to the last baseline, and the released fixes of all other components?” • "Given a list of fixes and enhancements, how do I configure a system that incorporates them?” • "This enhancement won’t be ready until the next release. How do I configure it out of the current baseline?” • "How exactly does this version differ from the Baseline?" • Status ing: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product. • "Has this problem been fixed?’’ • "Which bug fixes went into this copy?“ • "This seems like an obvious change. Was it tried before?” • "Who is responsible for this modification?” • "Were these independent changes merged?" • Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that the product is a well-defined collection of components
CM in a hardware-development environment • A computer has a processor, a mainboard, some memory, a hard drive, a monitor, and a keyboard. • Each of these hardware items has an interface that connects it to other hardware items. • Your mouse has a plug, and your computer has a port into which you plug your mouse, and makes everything works. • If the plug on the mouse was not compatible with the port on the computer, there would be no way to connect the two pieces of hardware into a working system.
• Throughout the computer, there are many other similar interfaces. • The processor and memory plug into the mainboard, the hard drive plugs into the computer, and the printer, monitor, and keyboard all have interfaces. • When the hardware is manufactured, the interfaces that are essential for the operation of the final system are easily seen. Therefore, they are well known and are carefully examined whenever changes are made to the hardware design. • For a hardware system, configuration management has the following aspects. • Each system is numbered or identified and also has a version number. Each version number identifies different designs of the same part. • When the design of a hardware system is changed, the system gets a new version number.
• A hardware system can be made up of hundreds, thousands, or tens of thousands of parts. • The next thing that must be recorded is which versions of these parts go together. • version of the mouse, hard drive, processor, and monitor go together to make a complete system. • Each of these parts, such as a hard drive, is made of many, many subparts, all of which must go together to have a working unit.
Software development and maintenance phases and CM
Configurati on manageme nt
Documenta tion CM
Code CM
WHY CM? • Software configuration management must ensure that: • software components can be identified; • software is built from a consistent set of components; • software components are available and accessible; • software components never get lost (e.g. after media failure or operator error); • every change to the software is approved and documented; • changes do not get lost (e.g. through simultaneous updates); • it is always possible to go back to a previous version; • a history of changes is kept, so that is always possible to discover who did what and when.
• Software develops from baseline to baseline until it can be released. • Changes to baselines must be controlled throughout the life cycle by documenting the: • problems, so that they can be understood; • changes that are proposed to solve the problem; • modifications that result. • ESA PSS-05-0 identifies five primary configuration management activities: • • • • •
configuration configuration configuration configuration release.
identification; item storage; change control; status ing;
Software Configuration Management Activities (Software configuration management plan)
SPMP – Software project management plan
Important concepts and in CM • Component Item (CI) • A CI is an aggregation of hardware, software or both that is designated as a unit for configuration management, and treated as a single entity in the configuration management process • A CI can be an aggregation of other CIs, organised in a hierarchy. • Any member of this hierarchy can exist in several versions, each being a separate CI.
• Examples of configuration items(CI) are: • software component, such as a version of a source module, object module, executable program or data file; • software item, such as a version of a compiler or a linker; • baseline, such as a software system under development; • release, such as a software system in operational use; • document, such as an ADD.
Types of CI • The type field of a CI identifier should identify the processing the CI is intended for. There are three main types of CI: • · source CIs; • · derived CIs; • · tools to generate derived CIs from source CIs.
Configuration identification • Configuration identification conventions should state how to: • name a CI; • decide who is the control authority of a CI; • describe the history of a CI.
• At the top level, the whole system is a CI. • Several factors may be relevant in deciding what to identify as the lowest level CI, such as the: • software design defined in the ADD and DDD (the lowest level of the software design sets the lowest possible level of configuration management); • capabilities of the software development tools (e.g. the units that the compiler or linkers input and output); • bottom-level work packages defined in the SPMP.
Baselines • A ‘baseline' is a CI that has been formally reviewed and agreed upon (i.e. approved), and declared a basis for further development. • Although any approved CI in a system can be referred to as a baseline, the term is normally used for the complete system. • Early baselines contain only documents specifying the software to be built; later baselines contain the code as well. • The CIs in a baseline must be consistent with each other. Examples of consistency are: • code CIs are compatible with the design document CIs; • design document CIs are compatible with the requirements document CIs; • manual CIs describe the operation of the code CIs.
Variants • The term ‘variant' is often used to identify CIs that, although offering almost identical functionality, differ in aspects such as: • · hardware environment; • · communications protocol; • · language (e.g. English, French).
• Variants may also be made to help diagnose software problems. • The usefulness of such variants is often temporary, and they should be withdrawn when the problem has been solved.
Configuration item control authority • Every CI should have a unique control authority that decides what changes will be made to a CI. • The control authority may be an individual or a group of people. • Three levels of control authority are normally distinguished in a software project: • · software author; • · software project manager; • · review board.
Software author • Software authors create low-level CIs, such as documents and code. • Document writers are usually the control authority for draft documents. • Programmers are normally the control authority for code until unit testing is complete.
Software project manager • Software project managers are responsible for the assembly of high-level CIs (i.e. baselines and releases) from the low-level CIs provided by software authors. • Software project managers are the control authorities for all these CIs. • Low-level CIs are maintained in software libraries. • On most projects the software project manager is ed by a software librarian.
Configuration item history • The development history of each CI must be recorded from the moment it is first submitted for review or integration. • For documents, this history is stored in Document Change Records (DCRs) and Document Status Sheets (DSS). • Change records in module headers should reference the Software Change Request (SCR) that actioned them. • For derived code, the development history is stored in the librarian's database. • The development history should include records of the tests that have been performed. • The Software Modification Report (SMR) should summarise the changes to CIs that have been revised in response to an SCR.
Configuration item storage • All CIs must be stored securely so that they never get lost. • Software projects can accumulate thousands of lowlevel CIs, and just as books are stored in libraries, it is necessary to store low-level CIs in software libraries. • The software libraries are themselves CIs. • Software CIs reside on hardware media (e.g. paper, magnetic disk). • Storage media must be maintained securely and safely so that software is never lost or its integrity compromised.
Software libraries • A software library is a controlled collection of configuration items (e.g. source module, object module and document). • Low-level CIs are developed and stored in libraries (e.g. source and object libraries), and then extracted to build high-level CIs (e.g. executable images). • As a minimum, every project must use the following software libraries to store CIs: • · development (or dynamic) libraries • · master (or controlled) libraries • · archive (or static) libraries
• Master libraries store CIs in the current baselines. • Archive libraries store CIs in releases or retired baselines. • CIs in archive libraries must not be modified
Access control to libraries • Access to software libraries should be controlled so that it is impossible: • · to access CIs without the correct authorisation; • · for two people to simultaneously update the same CI.
• Read access allows a CI to be examined or copied. • Insert access right allows a new CI to be added to a software library. • Delete access right allows a CI to be removed from a library. • Replace right allows a CI to be removed from a library and another version inserted.
Development staff access rights
Software librarian access rights
• Table 1 does not mean that a development library should be accessible to all developers • Apart from the software librarian, only the person directly responsible for developing or maintaining the CIs in a development library should have access to them. For sharing software, master libraries should be used, not development libraries. • Simultaneous update occurs when two or more developers take a copy of a CI and make changes to it. • When a developer returns a modified CI to the master library, modifications made by developers who have returned their CI earlier are lost. • A charge-in/charge-out or ‘locking’ mechanism is required to prevent simultaneous update.
Table 1: Development staff
Media control • All CIs should be stored on controlled media (e.g. tapes, disks). • Media should be labelled, both visibly (e.g. sticky label) and electronically (e.g. tape header). • The label should have a standard format, and must contain the: • • • •
· · · ·
project name configuration item identifier (name, type, version) date of storage content description
• Procedures for the regular backup of development libraries must be established. • Up-to-date security copies of master and archive libraries must always be available . • An aim of good media control is to be able to recover from media loss quickly.
VERSION CONTROL
• Version control • Management of multiple revisions of the same unit of information. • Changes identified by incrementing an associated number or letter code - “revision number”, or “revision level”. • Revision numbers (levels) are associated historically with the person making the change
• Repository • A server where the files are stored.
• Check-Out • copies a working copy from the repository • (the opposite of an import).
• Change • A specific modification to a document under version control. • The granularity of the modification considered a change varies between version control systems.
• Change List
• The set of changes made in a single commit. • A sequential view of the source code.
• Commit or Check-in
• Copy the changes on the local files to the directory. • (the VC software takes care of changes since the last synchronization).
• Update
• copies the changes that were made to the repository into your working directory. • (opposite of a commit).
• Merge / Integration • brings together (merges) concurrent changes into a unified revision.
• Revision or version • one version in a chain of changes.
• Conflict • Occurs when two changes are made by different parties to the same document or place within a document.
• Resolve • The act of intervention to address a conflict between different changes to the same document.
Example CM Clients
Trunk
CM Server Version A Branch
Machine A
Version A.1 Branch
Check Out Check In C
A
Machine B B Check Out D Merg e
E
Check In
Version B Branch
History • CM systems save the files’ history. • Old versions can be viewed, compared, and ed. • New versions can be (irreversibly) replaced with old versions and ‘wiped off the map’.
Central repositories • Files are saved in a central file server. • Developers can view the files in the repository, through the use of filters.
Labels • Several files can be labeled together. • Allows : • Access to the label as a whole set of files. • Changes to the labeled files as a unit.
• Useful for marking product releases.
Check-in • Copies a file into the database. • The version you see is (usually) the latest version that was checked in. • The old version is kept and can be accessed later.
Check out • Copies the database file to your personal folder, and raises a flag on the database copy. • Need to check out before checking in.
Undo check out (uncheck-out) • The “undo checkout” command does just that – the file returns to the status it had before it was checked out. • This can be done even if changes have been made to the local copy – of course, these do not go into the database!
Problems with file sharing • All version control systems have to solve the same fundamental problem: how will the system allow s to share information, but prevent them from accidentally stepping on each other's feet?
Scenario • Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system re every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident.
Versioning Models Lock-Modify-Unlock Solution:
• Only one person can change a file at a time. • Example: VSS. Copy-Modify-Merge Solution:
• s modify private copies only - in parallel • Private copies are merged together into a new, final version. • Example: CVS, Subversion.
The Lock-Modify-Unlock Solution
Problems With Locking • istrative problems: • A can lock a file and forget about it. • Time is wasted while others wait to edit the file.
• Unnecessary serialization: • Different parts of a file don’t necessarily overlap. • E.g.: Alice works on the beginning of a file, Bob wants to edit the end of the same file.
• False sense of security: • Let’s say Alice locks and edits file A, while Bob simultaneously locks and edits file B. • Let’s say A and B depend on one another, and the changes made to each are semantically incompatible. • Suddenly, A and B don't work together anymore.
The Copy-Modify-Merge Solution Aviva and Arik both check out file A. Here, checkout has no locking effect – it’s just a Read local copy. A
Repository A
Read
A
The Copy-Modify-Merge Solution Both edit their local files.
Repository A
Aviva Arik
The Copy-Modify-Merge Solution Aviva checks in her file to the repository first.
Repository Aviva
Write
Aviva
Arik
The Copy-Modify-Merge Solution Now, Arik tries to check-in his file. He gets an “upto-date check error” Write
Arik
Repository Aviva
Aviva
The Copy-Modify-Merge Solution Arik updates his local copy to contain the changes made by Aviva. Changes are added to the local file. During this merge, conflicts may occur.
Read
A’ (=Aviva+Arik )
Repository Aviva
Aviva
The Copy-Modify-Merge Solution A new merged file is created on Arik’s machine.
Repository Aviva
Aviva
B
The Copy-Modify-Merge Solution Arik commits his file to the repository.
Repository B
Write
B
Aviva
The Copy-Modify-Merge Solution Aviva updates her file from the repository.
Repository B
Read
B
B
THE SOFTWARE CONFIGURATION MANAGEMENT PLAN
Introduction • All software configuration management activities shall be documented in the Software Configuration Management Plan • Each SCMP section must document all software configuration management activities, specifically the: • • • • •
· organisation of configuration management; · procedures for configuration identification; · procedures for change control; · procedures for configuration status ing; · tools, techniques and methods for software configuration management; • · procedures for supplier control; • · procedures for the collection and retention of records.
• IEEE Guide to Software Configuration Management contains examples of plans for: • · a complex, critical computer system; • · a small software development project; • · maintaining programs developed by other activities or organisations; • · developing and maintaining embedded software.
• Configuration management procedures must be in place before software production (code and documentation) starts • Software configuration management procedures should be easy to follow and efficient. • Wherever possible, procedures should be reusable in later phases. • Instability in software configuration management procedures can impede progress in a software project.
About SCMP • STYLE • The SCMP should be plain and concise. • The document should be clear, consistent and modifiable. • The author of the SCMP should assume familiarity with the purpose of the software, and not repeat information that is explained in other documents.
• RESPONSIBILITY • The developer is responsible for the production of the SCMP.
• MEDIUM • It is usually assumed that the SCMP is a paper document. • There is no reason why the SCMP should not be distributed electronically to participants with the necessary equipment.
SCMP content
• Reference: • Guide to software configuration management by ESA Board for Software Standardisation and Control (BSSC), ESA PSS-05-09 Issue 1 Revision 1, March 1995 • Software Configuration Management Overview by Walter Tichy • http://svnbook.redbean.com/en/1.0/ch02s02.html
Thank you
Related Documents 3h463d
Configuration Management i171k
December 2019 38
December 2019 65
Configuration Management Best Practices 6k524c
December 2019 44
Configuration Management Process Guide 2r5c41
March 2023 0
Software Configuration Management 1s1ga
November 2019 42