Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 37|Likes:
Published by Kiran Kumar

More info:

Published by: Kiran Kumar on Nov 23, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Visual SourceSafe (VSS) is a client/server application which acts as a storage system for files.A file stored in a VSS server is not available via the standard file system, instead, it must beaccessed through the VSS client tools - the VSS windows client, the VSS command-line tool,or else some application which integrates with or emulates these client tools.The following discussion refers to version 6.0d. It contains three types of section:- Discussions of important concepts, headed like
.- Walk-throughs of development scenarios, headed like
.- Practical advice and best-practice, which......appears in shaded boxes.
VSS Database
 A VSS Database is a single instance of a VSS server - it's the big black box into which files getplaced. All commands to VSS are directed towards a particular VSS Database, and wachdatabase maintains a SRCSAFE.INI file which contains configuration information.
VSS Project 
 A VSS Database is organised as a tree structure, with each of the nodes of the tree being aVSS Project. Each database contains a single root project, which can branch (to a depth of 15nodes) into sub-projects.VSS Projects are misleadingly named; instead they should be thought of as directly analagousto filesystem directories, being unordered collections of up to 8000 files of any type. Toillustrate this, note that where an application's source-code is organised into files that live insubdirectories off the main directory, these subdirectories have to be mapped onto subprojectsof the application's main project directory.Don't confuse Visual Studio 'projects' with Visual Sourcesafe 'projects'. The latter are morelike directories, or folders. In fact, if you just think Visual Sourcesafe 'folder' where thedocumentation says Visual Sourcesafe 'project', it will be easier to follow.
Working Folder 
 Because the files stored in VSS are not directly exposed as files, development work on thesefiles takes place on local copies, which are first checked out of VSS, changed, then checked inagain. While a file is checked out of VSS, it is can be locked to other developers, preventingfile overwriting. VSS also retains historical information about a file's changes, so it is possibleto extract and use old versions of a file, or roll back unsuccessful changes.The folder in which a user manipulates his local copy of VSS project files is known as his'working folder'. Each user will often have a distinct, local working folder for each VSS project,the details of which are held by the VSS client in its SS.INI file.Each working folder also gets populated with a VSSVER.SCC file, which contains versioninformation about the files in that folder. This allows VSS quickly to determine whether or notlocal files are synchronised with those stored in the VSS database.
If it is possible that the source-code for your application may contain hard-coded file paths, itis important that developers' working folders are at the same location. One way of doing thisis to require each application's working folder to be at the root of a particular drive.
Building and Deployment 
 For non-web applications, their compilation and deployment is not under the control of VSS.The process that builds and deploys an application needn't integrate with VSS except toextract the latest instances of the files into a local directory where they can be manipulated asrequired.For web applications, VSS does support a 'deploy' command. This copies a project's files ontoa webserver, either directly or via FTP. However, for various reasons one might choose to useother methods of deployment with web applications.
Development Scenario: A
 Let's consider the situation in which two developers, UserA and UserB have to cooperativelydevelop a non-web application, are coming completely fresh to VSS, and neither uses an IDEto create the application.In this scenario we shall assume that each developer has a development machine, and thatthere is a development server which both of them can access. This gives us the following threecomputers: DevelopmentUserA; DevelopmentUserB; DevelopmentServerThe first thing that needs to be done is for a VSS database to be installed onDevelopmentServer, and the VSS client tools to be installed on the two developmentmachines. It's useful to know that the installation of VSS on DevelopmentServer sets up anetwork share to the installation directory, and the VSS client tools are available for users toinstall from there (this has the additional benefit that the client tools are set up with theDevelopmentServer database as the default).Next, the VSS database has to be set up with appropriate users. VSS handles its ownauthentication, rather than integrating with Windows authentication (though file access is stillsubject to NTFS permissions, of course), so it is necessary to set up individual accounts in VSSfor the two users.Next, the application development should start, and the application files should be added tothe VSS database. We shall assume that these application files are stored on UserA's personaldevelopment computer.The advice from those with experience of developing using VSS is that before adding files tothe VSS database it is useful to progress the development to a stage where the generalstructure of the application and its source code is mostly settled. This is because the processof renaming and moving application files can raise various small problems.As he is not using a VSS-integrated IDE, UserA will use the VSS client tool to add theapplication file to the database. To do this, he will need to point the client tool at theappropriate VSS database, which involves executing File -> Open SourceSafe Database andnavigating to the SRCSAFE.INI file on DevelopmentServer.After identifying the appropriate database, the following procedure will add all of theapplication source files to the database:
select the root project ($/)
execute File -> Add Files
navigate to the root directory of the application files (leaving the Relevant Masks at*.*) and press Add
add a descriptive comment, tick 'recursive', and press 'Add'
agree to make the source directory the 'working directory' for the current project.Alternatively, the required files may be dragged and dropped from Windows Explorer to theappropriate VSS project. This takes you to point 4 above.Once the files are in the VSS project, UserB will be able to view the project via the client tool.When he tries to access these files, he will be prompted to nominate a local working directory,and will be able to work on from that point.
Getting vs Checking Out 
If you 'Get' a file / project (which you do using the client tools by right-clicking on the itemand selecting 'Get Latest Version'), a read-only copy is placed into your working folder.Changes you make to this file cannot be subsequently uploaded to the VSS database.On the other hand, when you 'Check out' a file / project (which you do analagously to 'getting'it), a writable copy is placed into your working folder. By default, this locks the file to otherusers, so that while they may 'Get' a copy of the file they cannot themselves check it out.Notice that when you check out (and check in), you have the option to add a comment. This isto help developers keep track of the file changes.When either of these options is being applied to a project, the procedure can be appliedrecursively, so that it is applied to subprojects of the chosen project.
Checking In
 When you've finished making changes to a checked-out file / project, then you can check it inagain, which writes the file changes to the VSS database. This procedure is also effected in theclient tools using a right-click menu.By checking project files out and in using VSS, developers can avoid the situation in which oneoverwrites the changes made by another.Note that there are a few restrictions on filenames in VSS; for instance, they cannot containthe dollar sign ($).
Development Scenario: B
 Let's now consider the situation in which our two developers have to cooperatively develop anon-web application using Visual Studio .NET. In this case the VSS commands are integratedwith the IDE.The recommended structure for a .NET solution is to locate each project folder under thesolution folder (which is not the default: often, you create a project along with its solutionfiles, and the two go into the same directory). It is easy to get the recommended structurewhen creating the project – the important check box to tick when creating the solution /

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->