2.

Overview of Software Configuration Management

This section gives an overview of Software Configuration Management(SCM) in general. It focuses on defining what is SCM, the benefits of SCM and the adoption of SCM for OpenSource pro ects.

2.1. What is Software Configuration Management

Software Configuration Management is the abilit! to control and manage change in a software pro ect. Change is inherent and ongoing in an! software pro ect. The abilit! to trac" control such changes in a proper manner form the basis of a good software pro ect. Software Configuration Management tries to bridge this gap b! defining a process for change control. Change Management defines processes to prevent unauthori#ed changes, procedures to follow when ma"ing changes, re$uired information, possibl! wor"flow management as well. Change management is orders of magnitude more comple% than version control of software.

2.2. Why is Software Configuration Management required

SCM is the process that defines how to control and manage change. The need for an SCM process is acutel! felt when there are man! developers and man! versions of the software. Suffice to sa! that in a comple% scenario where bug fi%ing should happen on multiple production s!stems and enhancements must be continued on the main code base, SCM acts as the bac"bone which can ma"e this happen.

3. Traditional Software Configuration Management Pro ess

Traditional SCM process is loo"ed upon as the best fit solution to handling changes in software pro ects. Traditional SCM process identifies the functional and ph!sical attributes of a software at various points in time and performs s!stematic control of changes to the identified attributes for the purpose of maintaining software integrit! and traceabilit! throughout the software development life c!cle. The SCM process further defines the need to trace the changes and the abilit! to verif! that the final delivered software has all the planned enhancements that are supposed to be part of the release. The traditional SCM identifies four procedures that must be defined for each software pro ect to ensure a good SCM process is implemented. The! are Configuration Identification Configuration Control Configuration Status &ccounting Configuration &uthentication Most of this section will cover traditional SCM theor!. 'o not consider this as boring sub ect since this section defines and e%plains the terms that will be used throughout this document.

3.1. Configuration !dentifi ation

Software is usuall! made up of several programs. (ach program, its related documentation and data can be called as a )configurable item)(CI). The number of CI in an! software pro ect and the grouping of artifacts that ma"e up a CI is a decision made of the pro ect. The end product is made up of a bunch of CIs.

The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life c!cle. (ach new baseline is the sum total of an older baseline plus a series of approved changes made on the CI & baseline is considered to have the following attributes *. +unctionall! complete & baseline will have a defined functionalit!. The features and functions of this particular baseline will be documented and available for reference. Thus the capabilities of the software at a particular baseline is well "nown. ,. -nown .ualit! The $ualit! of a baseline will be well defined. i.e. all "nown bugs will be documented and the software will have undergone a complete round of testing before being put define as the baseline. /. Immutable and completel! recreatable & baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. &lso, all the CIs will be under version control so the baseline can be recreated at an! point in time.

3.2. Configuration Control

The process of deciding, co0ordinating the approved changes for the proposed CIs and implementing the changes on the appropriate baseline is called Configuration control. It should be "ept in mind that configuration control onl! addresses the process after changes are approved. The act of evaluating and approving changes to software comes under the purview of an entirel! different process called change control.

3.3. Configuration Status " ounting

Configuration status accounting is the boo""eeping process of each release. This procedure involves trac"ing what is in each version of software and the changes that lead to this version. Configuration status accounting "eeps a record of all the changes made to the previous baseline to reach the new baseline.

3.#. Configuration "uthenti ation

Configuration authentication (C&) is the process of assuring that the new baseline has all the planned and approved changes incorporated. The process involves verif!ing that all the functional aspects of the software is complete and also the completeness of the deliver! in terms of the right programs, documentation and data are being delivered. The configuration authentication is an audit performed on the deliver! before it is opened to the entire world.

3.$. Tools that aid Software Configuration Management

+ree Software Tools TO'O1 need some writeup here on each tool. +ree software tools that help in SCM are *. Concurrent 2ersions S!stem (C2S) ,. 3evision Control S!stem (3CS) /. Source Code Control S!stem (SCCS) Commercial Tools *. 3ational ClearCase ,. 42CS /. Microsoft 2isual SourceSafe

3.%. SCM and S&! Ca'a(ility Maturity Model

The Capabilit! Maturit! Model defined b! the Software (ngineering Institute (S(I) for Software describes the principles and practices to achieve a certain level of software process maturit!. The model is intended to help software organi#ations improve the maturit! of their software processes in terms of an evolutionar! path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is designed towards organi#ations in improving their software processes for building better software faster and at a lower cost. The Software (ngineering Institute (S(I) defines five levels of maturit! of a software development process. The! are denoted pictoriall! below.

&ssociated with each level from level two onwards are "e! areas which an organi#ation is re$uired to focus on to move on to the ne%t level. Such focus areas are called as -e! 4rocess &reas (-4&) in CMM parlance. &s part of level , maturit!, one of the -4&s that has been identified is SCM. Thus an! pro ect that has a good SCM process can be leveraged as satisf!ing one of the -4&s of CMM. 5e will cover this in more detail in the section on using SCM to leverage Open Source 4ro ects

#. SCM for O'en Sour e Pro)e ts

Open Source 4ro ects are t!picall! started b! a few talented individuals who wanted to )scratch a personal itch). It is then ta"en over b! the entire world (so it seems) and it grows in all directions, eventuall! magicall! solidif!ing into a product that is more stable than an! similar effort made b! human beings. In fact, OS4 at the outset, resemble a great ba#aar with different agendas and different approaches b! different people. 6ow important is SCM for such an Open Source 4ro ects pro ect7 8et us face it 0 OS4 wor"s and it wor"s well. So how are such diverse interests s!nergi#ed into a single mission7 8oo"ing at the e%tremel! successful 8inu% e%ample, 8inus Torvalds acts as the gate"eeper to the 8inu% "ernel. The actual development wor" is mostl! done b! others but 8inus Torvalds decides on the contents of the release "ernel. (ach developer sends to him a patch containing the changes that have to be incorporated into the "ernel. Thus for all practical purpose he acts as the one man software configuration management process offering control (incorporating patches from other developers), accounting (the changelog) and authentication of the configurable items (ensuring that the released "ernel has all the pieces) 0 9ot an eas! tas":

#.1. *eed for SCM in O'en Sour e Pro)e ts

SCM and its supporting tools bring order into the chaotic development model of Open Source 4ro ects. &ll SCM pro ects re$uire )maintainers) whole ob is to integrate the patches that arrive from various developers into the main code base, ma"e sure that things are in order and put out the releases in a regular fashion. The maintainers provide the SCM for free software pro ects. &ll successful OS4 pro ects involve one form of SCM or another. In fact the! emplo! all the procedures as defined in the traditional SCM process (See Section /). These procedures are evolved unconsciousl!. If we ma"e a conscious effort to incorporate the traditional SCM procedures into an OS4 pro ect, definite benefits can be obtained. In the future sections, 5e will loo" at various OS4 pro ects that are different in si#e and see how SCM can be effectivel! applied in those scenarios.

#.2. +sing SCM to leverage O'en Sour e Pro)e ts

& $uote comes to mind...

Ta"e a great idea, wor" ver! hard on it and then advertise even harder: 00&non!mous This adage applies to OS4 more than an!thing else does. Open Source 4ro ects re$uire publicit! as much, if not more, than an! other pro ect to be successful. OS4 pro ects to compete in the commercial space will re$uire building credibilit! with the e%ternal world. Credibilit! should be built starting with fellow developers to users to other large commercial software houses. One of the wa!s to build credibilit! is b! leveraging the fact that a clearl! defined SCM process e%ists and is followed for the OS4.

#.2.1. ,evelo'ers
'evelopers benefit from the e%istence of an SCM process since it ma"es their life easier. There is more clarit! as to who is responsible for what portion of the code, how and when their patches will be integrated into the main source tree and when software releases will be made. The e%istence of such an operational roadmap will help "eep the enthusiasm of the developer communit! thereb! ensuring good $ualit! software development.

#.2.2. Testers
In the OS4 communit!, a few people will act as the testers for the application b! setting up the new version on their s!stem and using it on a regular basis. To them, the availabilit! of an SCM will help in recreating a particular release of the software. The! can establish test beds easil! and compare multiple releases against each other to find out the cause of a particular bug;issue.

#.2.3. Su''ort Teams

There are a few groups and commercial organi#ations providing support for the 8inu% platform. Support can be in the form of providing total solution using Open Source software to providing telephone and;or email based support for customers who have businesses running on Open Source software. SCM can help them b! providing a means to $uic"l! setup a reference platform that contains the e%act same software version that is present at the customer site. Thus the! can reproduce the problem easil! and provide a wor"around or solution for it.

#.2.#. Cor'orate Management

8everaging Open Source to corporate management can be done in the following wa!s. *. (%istence of a formal process The e%istence of a formal process is alwa!s reassuring to the management. It signifies )professional approach) and e%istence of control in the pro ect. ,. Merges well with corporate culture Most commercial software organi#ations will have one form of SCM or another. Thus an! OS4 that is going to obtain a corporate bac"ing will benefit from SCM since the Software Configuration Management will help integrate the OS4 better with the organi#ation<s culture. /. Satisfies one or more -4&s of S(I<sCMM.

#.2.$. !nvestors
Investors and venture capitalists perform due diligence before investing in an! particular venture. 'ue diligence is the fanc! term for the e%ercise that attempts to find out whether the particular venture is worth investing into. Since I am not familiar with what is involved in due diligence, I will not be able to add finer points here. &ll the same, the e%istence of a defined process to manage the development will alwa!s help.

. SCM strategy in O'en Sour e Pro)e ts

5e will now e%amine SCM strategies for OS4 pro ects of different si#es and suggest suitable models for each. This should serve as a guideboo" for SCM when starting new OS4 pro ects

$.1. SCM for a small OSP

OS4 pro ects can be considered as )small si#ed) if the! fall within the following criteria. Small =ser >ase The user base of the OS4 pro ect will t!picall! be small in the order of magnitude, less than *??. One possible reason would be that the pro ect addresses a ver! niche area of a problem domain that does not interest the average public. &nother reason could be that the pro ect is ust starting out and so the user base is small due to its relative obscurit!. Small Code >ase The si#e (number of files;lines) of the source code for the application will t!picall! be small. Thus the various versions of the source code can be maintained without using a tool. 3eleases are not fre$uent In an! Open Source 4ro ects pro ect, the dictum is to )release earl! and release often). >ut some pro ects do not necessaril! have a need for fre$uent releases. Small si#ed OS4 pro ects tend to fall in that categor!. Such pro ects do not need a release management mechanism in place. &ppl!ing the traditional SCM procedures (See Section /) for a small Open Source 4ro ects, *. Configuration Identification +or a small pro ect, we have said that the code base will tend to be small. In that case, identif!ing configurable items can be a straight forward e%ercise. It will be the list of all the source files plus other documentation that accompanies the code. ,. Configuration Control

-.1 SCM Poli y

&n SCM polic! is what defines how !our organisation will manage software change. The basis of an effective SCM polic! is a revision control s!stem. &n SCM polic! can be as simple as a procedure in which C2S is used as a revision control s!stem and an understanding b! CM staff (documented or otherwise) in how releases are produced and distributed. &n SCM polic! should also include the implementation of some "ind of problem trac"ing s!stem. There are plent! of problem trac"ing s!stems available, ranging from lots of !ellow stic"! notes and shouting, to software pac"ages such as @9&TS or %pts. Man! organisations (far too man!, in m! opinion) have their own internall! developed problem trac"ing software pac"ages. & more comple% SCM polic! (perhaps based on MI80ST'0AB/) will include elements of Configuration Identification, Configuration Status &ccounting, and auditing procedures as well as all of the above items.

-.2 Configuration !dentifi ation

Configuration identification includes the selection of CIsC the determination of the t!pes of configuration documentation re$uired for each CIC the issuance of numbers and other identifiers affi%ed to the CIs and to the technical documentation that defines the CI<s configuration, including internal and e%ternal interfacesC the release of CIs and their associated configuration documentationC and the establishment of configuration baselines for CIs. DMI80ST'0AB/E

Configuration Identification is the process whereb! !our organisation selects and determines how the individual components of a software pro ect are to be identified. Fou can assist in the basic process of configuration identification b! following these procedures1 Ma"e sure that there e%ists a modules file in !our C2S repositor! (in the C2S3OOT director!). This is what C2S uses to identif! each software module. (nsure that there is a document somewhere (inside or outside of the repositor!) that describes each of the software modules, and what its purpose is. 4ut comments into the modules file that refer bac" to the document, or put e%tracts from the document into the C2S modules file as comments (remember that )modules) is a te%t file, not a word processing document, and each comment should be preceded with a hash sign 00 )G)). (nsure that there is an effective release procedure. The release procedure should involve a s!stem of tagging, identification, numbering, and bac"up. 3elease procedures are described in more detail later.

-.3 Configuration Control

Configuration Control is1

The s!stematic proposal, ustification, evaulation, coordiation, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a CI after establishment of the configuration baseline for the CI.

-.# !m'lementation of Configuration Control

6aving established a change authorisation procedure, !our organisation will be in a position to use C2S as a change control mechanism. &s stated previousl!, C2S cannot be used as a change authorisation method, and so at best it provides one half (the machine half) of the configuration control polic! that !our organisation re$uires. The process of implementing configuration control includes the following1 3estricting access to the C2S repositor! to allow authorised changes onl!. (nsuring that established product baselines are changed b! virtue of wor" authorities onl!. & wor" authorit! in this case will be a change re$uest derived from a trouble report or an engineering change. In the C2S repositor!, there is a director! called )C2S3OOT). This director! contains a number of control files used b! C2S. These files are site0dependant (that is, the! can be modified and maintained b! the C2S administrators at each C2S site), and can be used b! !our site to implement configuration control. In section B.H.* (3elease strategies) I e%amined two possible architectures of release methods using C2S tags. These depend on whether local builds are created from tagged or head revisions from the C2S repositor!. If !ou are building local builds from head revisions, !our organisation will need to perform configuration control at the commit stage. If !ou are building local builds from tagged revisions, !our organisation will need to perform change control at the tag stage.

" version ontrol glossary

.el' inde/ &bout source code version control with C2S & version control glossar! 5hat is version control7 -e! terms in version control The cop!0modif!0merge development c!cle =sing command0line C2S to access pro ect source files Managing pro ect files and directories with C2S

What is version ontrol0

& version control s!stem maintains an organi#ed set of all the versions of files that are made over time. 2ersion control s!stems allow people to go bac" to previous revisions of individual files, and to compare an! two revisions to view the changes between them. In this wa!, version control "eeps a historicall! accurate and retrievable log of a file<s revisions. More importantl!, version control s!stems help several people (even in geographicall! disparate locations) wor" together on a development pro ect over the Internet or private networ" b! merging their changes into the same source repositor!.

1ey terms in version ontrol

Chec"ing in a file or director! This copies !our wor"ing director! bac" into the repositor! as a new version. Chec"ing out files or directories This copies the latest revision of a file from the repositor! to !our wor"space. 5hen !ou chec" out a director!, !ou chec" out all files and subdirectories under it. Committing a file or director! This is the same as chec"ing in a file or director!. Often version control users will sa! that the! have )committed a change)C this means that the! made changes to their wor"ing copies of files and committed these bac" to the repositor!. Conflict 5hen two developers ma"e changes to their wor"ing copies of the same file and commit them to the repositor!, their wor" ma! conflict. 5hen this happens, C2S will detect the conflict and re$uire someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different wor"ing copies of the same files in the source repositor!. Merging is a strateg! for managing conflicts b! letting multiple developers wor" at the same time (with no loc"s on files), and then incorporating their wor" into one combined version. Merging wor"s well when two sets of changes are made to different lines in a files and can be easil! combined. 5hen changes to a file are made on the same line or lines, conflicts occur, re$uiring someone to edit the

file manuall! before the changes can be committed to the source repositor! successfull!. 3epositor! & shared database with the complete revision histor! of all files under version control. 3esolving Conflicts within a file created b! two developers attempting to commit conflicting changes must be addressed b! manuall! editing the file. Someone must go through the file line b! line to accept one set of changes and delete the other set. +iles with conflicts cannot be committed into the source repositor! successfull! until the! are resolved. 3evision & numbered draft of specific updates to individual files. (ach time !ou edit a file and commit it bac" to the repositor!, the file<s revision number increases. 2ersion The numbering scheme used to identif! sets of files that are tagged and named at a certain point in time. 5or"space Four copies of the files !ou want to edit on !our local hard dis" or =ni% user account. 5hen !ou edit files in !our wor"space, the! will become out of s!nc with the repositor!. That<s progress: Then !ou need to get !our changes bac" into the repositor! so that ever!one else can see them.

The o'y2modify2merge develo'ment y le

>ecause C2S is a vastl! powerful tool, the learning curve might seem formidable. Certainl! there are plent! of boo"s and web sites offering comprehensive C2S "nowledge bases (man! good sources are referenced at the bottom of this site<s main C2S page). 6owever, it is not necessar! to digest an entire tome to be able to incorporate C2S into !our software development practices immediatel! and effectivel!. C2S allows !ou to wor" within !our own development c!cle while "eeping trac" of the pro ect<s overall development c!cle1 *. Fou begin wor"ing on a pro ect b! obtaining !our own wor"ing cop! of files, "nown as checking out the pro ect repositor! or modules, individual groups of pro ect source files. ,. Fou ma"e !our contributions to the pro ect b! modif!ing these files and creating new files. This part of the c!cle doesn<t involve cvs directl!. Fou modif! !our wor"ing copies of pro ect files using a file editor on !our local machine. Fou can save and compile !our edited files to test how !our changes affect the particular pro ect module !ou are wor"ing in without affecting an!one else<s wor" on those same pro ect files. 9othing !ou do affects other pro ect participants until !ou merge !our changes into the pro ect repositor!. /. Fou test and twea" !our latest changes in !our own wor"space to ma"e sure these wor" without brea"ing or corrupting the overall pro ect. I. +inall!, !ou contribute bac" or check in !our changes to the main or )top) bod! of pro ect files, merging !our wor" with the most recent wor"ing version "nown in C2S terminolog! as the head.

Committing !our changes to merge with other developers< wor" is the most powerful aspect of C2S, but that power also ma"es it the most critical aspect. It<s possible to get confused and accidentall! overwrite someone else<s changes or !our own. Four contributed changes invariabl! will conflict with someone else<s at some point. =nderstanding how and when to update !our wor"ing copies and how to resolve merge conflicts are two particularl! critical aspects of using C2S in collaborative development pro ects. This copy-modify-merge cycle is repeated throughout the life of the pro ect b! all contributing developers. C2S enables ever!one to wor" on pro ect files simultaneousl!, to sta! up to date on the latest changes contributed b! others, and to test how their own changes affect the overall pro ect without interrupting other developers< c!cles.

" version ontrol glossary

.el' inde/ &bout source code version control with C2S & version control glossar! 5hat is version control7 -e! terms in version control The cop!0modif!0merge development c!cle =sing command0line C2S to access pro ect source files Managing pro ect files and directories with C2S

What is version ontrol0

& version control s!stem maintains an organi#ed set of all the versions of files that are made over time. 2ersion control s!stems allow people to go bac" to previous revisions of individual files, and to compare an! two revisions to view the changes between them. In this wa!, version control "eeps a historicall! accurate and retrievable log of a file<s revisions. More importantl!, version control s!stems help several people (even in geographicall! disparate locations) wor" together on a development pro ect over the Internet or private networ" b! merging their changes into the same source repositor!.

1ey terms in version ontrol

Chec"ing in a file or director! This copies !our wor"ing director! bac" into the repositor! as a new version. Chec"ing out files or directories This copies the latest revision of a file from the repositor! to !our wor"space. 5hen !ou chec" out a director!, !ou chec" out all files and subdirectories under it. Committing a file or director! This is the same as chec"ing in a file or director!. Often version control users will sa! that the! have )committed a change)C this means that the! made changes to their wor"ing copies of files and committed these bac" to the repositor!. Conflict 5hen two developers ma"e changes to their wor"ing copies of the same file and commit them to the repositor!, their wor" ma! conflict. 5hen this happens, C2S will

detect the conflict and re$uire someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different wor"ing copies of the same files in the source repositor!. Merging is a strateg! for managing conflicts b! letting multiple developers wor" at the same time (with no loc"s on files), and then incorporating their wor" into one combined version. Merging wor"s well when two sets of changes are made to different lines in a files and can be easil! combined. 5hen changes to a file are made on the same line or lines, conflicts occur, re$uiring someone to edit the file manuall! before the changes can be committed to the source repositor! successfull!. 3epositor! & shared database with the complete revision histor! of all files under version control. 3esolving Conflicts within a file created b! two developers attempting to commit conflicting changes must be addressed b! manuall! editing the file. Someone must go through the file line b! line to accept one set of changes and delete the other set. +iles with conflicts cannot be committed into the source repositor! successfull! until the! are resolved. 3evision & numbered draft of specific updates to individual files. (ach time !ou edit a file and commit it bac" to the repositor!, the file<s revision number increases. 2ersion The numbering scheme used to identif! sets of files that are tagged and named at a certain point in time. 5or"space Four copies of the files !ou want to edit on !our local hard dis" or =ni% user account. 5hen !ou edit files in !our wor"space, the! will become out of s!nc with the repositor!. That<s progress: Then !ou need to get !our changes bac" into the repositor! so that ever!one else can see them.

The o'y2modify2merge develo'ment y le

>ecause C2S is a vastl! powerful tool, the learning curve might seem formidable. Certainl! there are plent! of boo"s and web sites offering comprehensive C2S "nowledge bases (man! good sources are referenced at the bottom of this site<s main C2S page). 6owever, it is not necessar! to digest an entire tome to be able to incorporate C2S into !our software development practices immediatel! and effectivel!.

C2S allows !ou to wor" within !our own development c!cle while "eeping trac" of the pro ect<s overall development c!cle1 *. Fou begin wor"ing on a pro ect b! obtaining !our own wor"ing cop! of files, "nown as checking out the pro ect repositor! or modules, individual groups of pro ect source files. ,. Fou ma"e !our contributions to the pro ect b! modif!ing these files and creating new files. This part of the c!cle doesn<t involve cvs directl!. Fou modif! !our wor"ing copies of pro ect files using a file editor on !our local machine. Fou can save and compile !our edited files to test how !our changes affect the particular pro ect module !ou are wor"ing in without affecting an!one else<s wor" on those same pro ect files. 9othing !ou do affects other pro ect participants until !ou merge !our changes into the pro ect repositor!. /. Fou test and twea" !our latest changes in !our own wor"space to ma"e sure these wor" without brea"ing or corrupting the overall pro ect. I. +inall!, !ou contribute bac" or check in !our changes to the main or )top) bod! of pro ect files, merging !our wor" with the most recent wor"ing version "nown in C2S terminolog! as the head. Committing !our changes to merge with other developers< wor" is the most powerful aspect of C2S, but that power also ma"es it the most critical aspect. It<s possible to get confused and accidentall! overwrite someone else<s changes or !our own. Four contributed changes invariabl! will conflict with someone else<s at some point. =nderstanding how and when to update !our wor"ing copies and how to resolve merge conflicts are two particularl! critical aspects of using C2S in collaborative development pro ects. This copy-modify-merge cycle is repeated throughout the life of the pro ect b! all contributing developers. C2S enables ever!one to wor" on pro ect files simultaneousl!, to sta! up to date on the latest changes contributed b! others, and to test how their own changes affect the overall pro ect without interrupting other developers< c!cles. 5hat is version control7 & version control s!stem maintains an organi#ed set of all the versions of files that are made over time. 2ersion control s!stems allow people to go bac" to previous revisions of individual files, and to compare an! two revisions to view the changes between them. In this wa!, version control "eeps a historicall! accurate and retrievable log of a file<s revisions. More importantl!, version control s!stems help several people (even in geographicall! disparate locations) wor" together on a development pro ect over the Internet or private networ" b! merging their changes into the same source repositor!. -e! terms in version control

Chec"ing in a file or director! This copies !our wor"ing director! bac" into the repositor! as a new version. Chec"ing out files or directories This copies the latest revision of a file from the repositor! to !our wor"space. 5hen !ou chec" out a director!, !ou chec" out all files and subdirectories under it. Committing a file or director! This is the same as chec"ing in a file or director!. Often version control users will sa! that the! have )committed a change)C this means that the! made changes to their wor"ing copies of files and committed these bac" to the repositor!. Conflict 5hen two developers ma"e changes to their wor"ing copies of the same file and commit them to the repositor!, their wor" ma! conflict. 5hen this happens, C2S will

detect the conflict and re$uire someone to resolve resolve it before committing their changes. Merging Combining multiple changes made to different wor"ing copies of the same files in the source repositor!. Merging is a strateg! for managing conflicts b! letting multiple developers wor" at the same time (with no loc"s on files), and then incorporating their wor" into one combined version. Merging wor"s well when two sets of changes are made to different lines in a files and can be easil! combined. 5hen changes to a file are made on the same line or lines, conflicts occur, re$uiring someone to edit the file manuall! before the changes can be committed to the source repositor! successfull!. 3epositor! & shared database with the complete revision histor! of all files under version control. 3esolving Conflicts within a file created b! two developers attempting to commit conflicting changes must be addressed b! manuall! editing the file. Someone must go through the file line b! line to accept one set of changes and delete the other set. +iles with conflicts cannot be committed into the source repositor! successfull! until the! are resolved. 3evision & numbered draft of specific updates to individual files. (ach time !ou edit a file and commit it bac" to the repositor!, the file<s revision number increases. 2ersion The numbering scheme used to identif! sets of files that are tagged and named at a certain point in time. 5or"space Four copies of the files !ou want to edit on !our local hard dis" or =ni% user account. 5hen !ou edit files in !our wor"space, the! will become out of s!nc with the repositor!. That<s progress: Then !ou need to get !our changes bac" into the repositor! so that ever!one else can see them.
The cop!0modif!0merge development c!cle >ecause C2S is a vastl! powerful tool, the learning curve might seem formidable. Certainl! there are plent! of boo"s and web sites offering comprehensive C2S "nowledge bases (man! good sources are referenced at the bottom of this site<s main C2S page). 6owever, it is not necessar! to digest an entire tome to be able to incorporate C2S into !our software development practices immediatel! and effectivel!. C2S allows !ou to wor" within !our own development c!cle while "eeping trac" of the pro ect<s overall development c!cle1

Fou begin wor"ing on a pro ect b! obtaining !our own wor"ing cop! of files, "nown as checking out the pro ect repositor! or modules, individual groups of pro ect source files. ,. Fou ma"e !our contributions to the pro ect b! modif!ing these files and creating new files. This part of the c!cle doesn<t involve cvs directl!. Fou modif! !our wor"ing copies of pro ect files using a file editor on !our local machine. Fou can save and compile !our edited files to test how !our changes affect the particular pro ect module !ou are wor"ing in without affecting an!one else<s wor" on those same pro ect files. 9othing !ou do affects other pro ect participants until !ou merge !our changes into the pro ect repositor!. /. Fou test and twea" !our latest changes in !our own wor"space to ma"e sure these wor" without brea"ing or corrupting the overall pro ect. I. +inall!, !ou contribute bac" or check in !our changes to the main or )top) bod! of pro ect files, merging !our wor" with the most recent wor"ing version "nown in C2S terminolog! as the head. Committing !our changes to merge with other developers< wor" is the most powerful aspect of C2S, but that power also ma"es it the most critical aspect. It<s possible to get confused and accidentall! overwrite someone else<s changes or !our own. Four contributed changes invariabl! will conflict with someone else<s at some point. =nderstanding how and when to update !our wor"ing copies and how to resolve merge conflicts are two particularl! critical aspects of using C2S in collaborative development pro ects. This copy-modify-merge cycle is repeated throughout the life of the pro ect b! all contributing developers. C2S enables ever!one to wor" on pro ect files simultaneousl!, to sta! up to date on the latest changes contributed b! others, and to test how their own changes affect the overall pro ect without interrupting other developers< c!cles.

*.

Cigital 8abs J 3esources J 'efinitions J Software Inspection Software inspection is the manual processes of reading code to detect errors. Software inspection is neither automated parsing, nor is it d!namic testing. @enerall!, software inspection is carried out onl! b! persons other than those who wrote the code. 6aving independent opinions almost certainl! improves the number of defects found b! this process. Software inspection has been used for man! !ears, b! such luminaries as >abbage and von 9eumann. Other professions have similar procedures (e.g., financial auditors, medical second opinions, building inspectors, etc.). Software inspection was much more mainstream in the K?<s and B?<s, because of the difficult! of getting access to computer time. In the earl! da!s, it was not uncommon for a user to submit punched cards and then wait for one or more da!s before the results were returned. >ecause of this time lag, it was prudent for the developer to detect all s!ntactic errors before submitting a ob. 5ith computer resources scarce and programs of smaller si#e than toda!<s s!stems, performing careful inspections of the code before compilation and e%ecution was easil! achieved. &lthough programs are huge toda!, software inspection is ma"ing a comebac". It should be obvious wh! software inspection detects errorsC after all, having more e!es staring at code onl! serves to improve its $ualit!. +reedman and 5einberg report that in large s!stems, inspections reduced the number of errors going into testing b! a factor of *? D*E. The advent of personal computer and compilers for 4Cs, caused developers to become la#! and start hac"ing together code, immediatel! tr!ing to compile and run it. 8a#! coders emplo! debuggers to tr! to find errors. >ecause of this, inspections got lost for a time, but toda!, inspections are bac" in heav! use, as it is widel! "nown that fi%ing errors before a s!stems goes into test is e%tremel! cost0effective. Software inspection can be performed at a variet! of different levels. +or e%ample, there are code walkthroughs, that e%amine source code but ignore design and re$uirements documents. Formal reviews re$uire that someone familar with the code introduce the rest of the inspectors to the code. These are more li"e presentations where the code itself is the sub ect manner. T!pical inspections are not onl! geared toward error detection but also ensure that particular coding standards and issues such as portabilit! are enforced