Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality
1
Lab1: CM – MS SourceSafe (12 points total)
This lab consists of three parts:
1. Admininistrator tutorial,
2. User tutorial, and
3. The actual Lab exercises.
2
Administration Functions
2.1 File


Open (existing) SourceSafe Databases
New Database (creation)
2.1.1 Create a new repository
 File
 Create Database
 Browse
 S:\Courses\CSSE\rowemi\3730\ . . .
 Name of repository
 Version Control Model: Lock-Modify-Unlock
2.1.2 Open the Repository
 File
 Open SourceSafe Repositories
 Browse
 browse to S:\Courses\CSSE\rowemi\3730\. . .
 select “srcsafe.ini”
 Open
 OK
After the open dialog closes you should only see the admin and guest users. These are
the only current users for this repository. You will need to add the users for your Lab
team.
3
Users




Add (new) User – A user id is associated with only 1 db. This allows different
privileges to be set for each db.
Delete User
Edit User – Changes name and access (cannot edit Admin)
Change Password
© 2011 Mike Rowe
Page 1
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality
3.1
Add Users to your database for your team
 Users
 Add User Select a users name and password “bubba” and “beer”
Need to specify what “bubba” can and cannot do.
 Tools
 Options
 General Tab
 unselect the options that you don’t wish
 “Allow multiple checkouts” // only exclusive one person check out of
a file at a time, and
 “Auto network login” // use network userid’s and passwords
 “Only allow checkout of latest versions”
 Only going to have one DB so we don’t need a default DB
 Don’t specify a keyword expansions for any file types
 We may want to select a file to journalize all session commands for each user.
If you so choose, make sure that it is in your team’s directory.
 OK // sets the options
Project Rights Tab
 Enable
 Deselect “Destroy” // why would we want this away?
 OK // sets the options
 In the Tools Menu select Rights by Project
Select Proj1
Select Guest
In the bottom of the window uncheck all rights except Read
// This limits the Guest User to only Read access of the files in this subproject.
// This is useful to define project roles – Coder has all access to code but only
// read access to Requirements.
Shadow folder Tab {{ optional }}
A Shadow is a central, optional folder that contains current versions of all the
files in a project. (kind of like RAID 1) Whenever a file is added or checked into
the repository the file is automatically added or updated in the Shadow folder.
The Shadow folder does not contain the master copy of a file or the local copy
of a file. Instead, it provides a central location from which to view the overall
structure of the project and serves as a convenient place to build or compile the
project.
It can also be used as a backup, although it does not contain any history.
 Web Projects And Web Tabs {{ optional }}
VSS provides utilities for maintaining the files that implement a web site (see
online help for the details). QA Tools include
 Tracks versions of files that make up a web site
 Check Hyperlinks between files in a project
© 2011 Mike Rowe
Page 2
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality



Create Site Map, which builds HTLM file that contains tags to the files in
a project.
Deploys a project’s files to a web server
Allows specification of a proxy for deploying via ftp
3.2 Other Admin Options
3.2.1 Server
Allow the setup for use of VSS over HTTP or HTTPS. (See online help for details).
3.2.2 Archive
Allows the backup and restore of repositories.
3.2.3 Help
A not too shabby online manual.
3.2.4 Analyze
It is a good practice to run analyze. It scans your repository for integrity issues and can also fix
most problems. Analyze is run periodically on a repository (automatic mode). You can also run
it manually from a command line or batch file. The below command analyzes and repairs a
complete repository and produces verbose output.
analyze -C -D -F -V4 C:\VSS\Data
-C
Cleans up and compresses unused space in the database
-D
Deletes any unused files. Deletion recovers space taken up by files and projects that
have been purged.
-F
Automatically repairs inconsistencies and corruption that are detected, as long as no
users are logged in.
-V4
Displays all errors and warnings, inconsistencies, and informational notes.
Note as of Sept 2011 there seems to be some file system inconsistencies that produce false
alarms when running analyze on a Novel network drive.
4
Client view
4.1 File


Open SourceSafe DB // if your user id can see multiple DB
Add files // at the current level -- you can also drag and drop from Windows Explorer
© 2011 Mike Rowe
Page 3
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality




Create Project // creates a subdirectory under $/ -- the root of your DB -- you can also
drag and drop from Windows Explorer
Add/Delete/Rename/Move/Properties of Files
Set Working Folder // where your files will be checked out to by default, your
“workspace”
Labeling of files // can associate specific versions of files with a specific Label like 1.0.
A Label can be used to pull all files with a specific Label to build a release.
4.2 Edit


4.3


4.4



4.4.1

View/Edit
Select/Invert Select/Select All
o Allows one to select files in current Project Path using a pattern “*.html”
View
Sort
Search
o Very useful, can find all files checked out – if you need to do a build you can find
out who is still working on stuff so that you can contact them to find out when a
file will be ready for a build.
Versions
Checkout/Checkin/Get Latest Version/Undo Checkout
Merge Branches – copies all changes made in one branch to another branch.
Share
o Shares the current version of a file to make it a member of the current
project or shares the current version of a project to create a new subproject.
 If you branch a shared file, changes made in the branched file no
longer propagate to the file versions in other projects. Similarly,
changes made to the file in the other projects no longer propagate
to the branched file.
o It can also be used to branch a version of a file.
 This is useful if you need to make changes for an upcoming release –
you can work on a branched version of a file without affecting the
robustness of deployed software. Later the branch can be merged
back to the main line.
Tools
Show History/Report
© 2011 Mike Rowe
Page 4
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality






4.4.2
o Can select just the history that one wants. For instance, look for all the files that
have been checked in since the last build, so that we can determine what needs to
be rebuilt or retested. If a critical library/include has changed we may need to
rebuild the world. It also helps trim down the scope of what will need to be
retested.
o Once the Show History is run one can produce some very useful reports (see
Reports).
PINNING – Files can be pinned. A file that is pinned cannot be changed. KNOW WHAT
THIS IS ABOUT!
o If a file is already pinned then shared and the pinned version of the file cannot be
changed. This is very useful when you need to greatly restrict changes to a system.
o If a file is shared first and then pinned in another project, then projects that were
shared prior to the pin can still change and update the file.
 If you have deployed version 1.0, have started working on version 2.0, and you
need to send out a bug fix for version 1.0, then Pinning is very useful. You
create a v1.1 project, share v1.0 with v1.1 (v1.0 may already be pinned because
it have been deployed), all files in v1.1 may now also be pinned, select only
those files in v1.1 that need to be changed to unpin. Later v1.1 changed files
can be merged with v2.0.
Show Differences – Diff two files. Additional options for diff can be found on the
Tools/Options/Difference menu.
Find in Files– Grep for a string
Report – Simple report of the current files in the repository.
Change Password for the current user.
Options/Customize toolbar/ etc.
o This allows one to set up their working environment the way they want it.
Warning – it is generally good to keep all warnings turned on.
o You can change/add default editors associated with different file types. Example:
use Notepad++ for html files.
Web
If the Admin has created this project as a Web Project
o Check Hyperlinks
 Ever been to a web page and clicked on a bad link? This runs all of the
hyperlinks in a project to make sure they are valid.
o Create Site Map //Generates a list of tags for the files in the website like


<A HREF="http://www.uwplatt.edu" >U.W. Platteville</A>
<A HREF="http://www.uwplatt.edu/~rowe" >mikes</A>
o Deploy //Blasts out a new version of website. Can specify ftp proxy, etc.
© 2011 Mike Rowe
Page 5
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality
5
Lab 2 Team Exercise: Configuration Management Systems
5.1 Due date: 9/30 8:00 am
5.2 Purpose:
Gain practical experience with a commercial Configuration Management System.
5.3 Process
NOTE make sure that you read each step completely before doing that step.
5.3.1 Admin tasks
1. Using the SourceSafe Admin create a repository for your team.
2. Now add users for each of your team members, plus Bubba, Billiebob, Bobob, and Rowemi.
3. Except for Rowemi, give each a unique password. Rowemi should not have a password
(otherwise I cannot grade your work).
4. Set up a Shadow of your repository at the root level of your groups shared disk. Call it
“SHADOW”
5. Go into tools and disable file destruction and disable multiple checkouts.
6. Exit the Admin and logon to the client under one of the new accounts.
5.3.2 Client Tasks
1. Create a Project under “$/” called “QuizQuestions”.
2. Create a SubProject under the “QuizQuestions” project called “09_20”
3. As a group talk about and come to a consensus as to what information should be in a
comment. From this point to follow your policy. A policy generally contains the reason for
checking out/in a module.
************************************************************************
*** From this point on include the step number in every checkout/checkin comment ***
*** For instance the next step is #4, the Checkin comment could be something like ***
*** “Step # 4: adding new file to the repository”
***
*************************************************************************
© 2011 Mike Rowe
Page 6
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality
4. Create an ASCII file using notepad or similar ASCII editor on your desktop and compose a
quiz question about CM (don’t add any choices yet). Save the file as “Q1.txt” on the
desktop. Add this file to your repository under the “09_20” subproject by dragging it from
the desktop into the SourceSafe subproject. Note: you can add entire folders using the
drag and drop option – if doing this make sure to check the recursive box.
5. We need to make a “bug fix” branch for the “09_20” subproject. Do this by:
a. Create a new project under the root level called “BugFix”.
b. Select the “BugFix” project in the SourceSafe main explorer window.
c. Select Version Share. Select 09_20 project with which to share. Make sure that
you check the “branch after share” check box at the bottom of the dialog, then click
the SHARE button. Note the “branch after share” option places a copy of the files in
the destination branch, otherwise the files are shared between the two projects and
changes in one project will result in changes in the other. This would be good if you
have certain files that must stay in sync across multiple projects.
d. A new dialog should appear, change the file name to “Experimental.txt”, click OK.
Note this may take a little time over the network. When you get back to the main
SHARE dialog click CLOSE.
e. You should now see a bug fix branch.
6. In the BugFix branch Checkout the “Experimental.txt” file, add one choice to the question,
and check in the file.
7. In the original 09_20 path Checkout, add a different answer choice to original file (the one
named “Q1.txt”, and check in the file.
8. Select the root and run a Show History (see Tools in main menu bar), check recursive
option. With the report in view, click the Report button on the right. In the History Report
Dialog, select the “Include details” and the “Include differences”; then Preview the report.
You do not need to print this LONG report, unless you want to.
9. Create another Project under the root level and call it “09_29”
10. Create SubProject under “09_29” for each person on your team using your novel user ids as
SubProject names.
11. Create a text file (use NotePad) called “Q2.txt” with just the word Questions in it.
12. Whoever is logged on at the moment, Add this file to their subproject (created in step # 10)
of your user id. Make sure that you are following your checkin comment policy.
13. Each person in your group successively, login to SourceSafe as yourself , checkout the file,
edit the question (just put your name in the file and something simple) and check the
question back in. Make sure that you add appropriate comments with the checkout and
checkin actions – this should include reason for action.
14. Create a Report from “$/” (root level), with recursion, details, and differences. Save the
report to a file. This history file is a deliverable for this project!
© 2011 Mike Rowe
Page 7
03/16/2016 12:35 AM
Lab_002
Configuration Management
SE 3730 / CS 5730 – Software Quality
15. Figure out how to delete a file and then how to undelete it. Describe this in you lab report
Deliverables Section.
16. Go back into the SourceSafe Admin.
a. Set the “Guest” user’s access to only READ for the “09_20” project.
b. Go back to the SourceSafe Client side and try to checkout a file from the “09_29”
path. Report what happens in the Lab Report Deliverables section.
17. Complete the lab report (see the example form link to the class web page) describing the
lab.
18. At the top of the lab report copy and paste the grading Rubric – this will save me time in
grading it.
19. When you have completed the lab report email the lab report and the report created in
step # 14 it to me and cc each member of you team.
20. At this point feel free to try stuff. It is pretty bullet proof, so the chances of anything getting
messed up is remote.
21. Look at the HELP if you haven’t been there already.
22. Look at the interface from MS Visual Studio. The interface may have been clobbered by the
installation of Rational software on some of the workstations. Visual Studio projects are
nicely integrated with VSS. I think the synchronization problems between checkouts from
VSS and Visual Studio have been fixed with this version.
23. Look at the command line interface that is available (HELP would be a good place to look).
In most installations, checkin and checkout is done via scripts that require certain
information be entered to enforce comment policies (like every checkin or checkout must
be associated with a development requirement or a defect/change request reference). The
scripts also allow VSS to be integrated directly to several Defect and Change Control
systems.
SE 373/573 Software Quality Lab 002 CM Lab
Grading Rubric
Task
Max
Points Comments
Points
Report
2
CM tasks
Admin
3
Client
5
Form and Style
2
TOTAL
12
© 2011 Mike Rowe
Page 8
03/16/2016 12:35 AM