Apply Microsoft Visual SourceSafe organization software development project
source:
Microsoft Research:
Microsoft
Abstract Professional software development requires pipeline processing on the management of the source code modification of each application during the development process. Microsoft_ Visual SourceSafe? Record history of system, projects, and file-level modifications, allowing you to securely distribute development work between multiple programmers, track modification information, and restore individual files or earlier versions of the entire application. Introduction The code is a valuable resource. To protect it, many developers apply some version control systems to protect files to avoid unauthorized modifications and accidents. These systems have many kinds of complicated software systems that have changed from program annotations and the older version of the gentleman agreement to automatic tracking modifications and history. Most source control systems are effective for separate source files. However, they can't build relationships between files. This will cause problems in Microsoft Windows environments, because in this environment, an application can contain multiple executables and dynamic connection libraries established by many different source files, which may be repeated in many other applications. use. Today, the relationship between management source files and the content of the protected source file are equally important. Microsoft Visual SourceSafe version control software solves this problem by combining the task of the project management and the source code. To manage projects while manageing source files, Visual SourceSafe provides excellent solutions for this issue, which is not easy to implement with standard, file-oriented source control systems. Software Development Tailor line In order to understand the advantages of the project-oriented source control, it is only necessary to compare it and file-oriented systems. A standard version control system (eg, UNIX Tool RCS) is inevitably a set of tools for operating separate files, control file access, and update and with earlier versions. To operate a set of files, you need to write a batch file or specify a wildcard in the command line. Microsoft Visual SourceSafe stores files in the center of the network instead of being in a normal DOS directory. In the system level, the database appears as a "black box". However, when Visual SourceSafe is a view, you can see all source files and history of your organization to the project hierarchy. When you retrieve a file, Visual SourceSafe will bid the file in the database to check out, then allow you to modify the file on your machine. When you put this file back, Visual SourceSafe updates its database and re-modify your machine's access to files to read-only. However, what is the difference between this and the file-oriented source control? For each change, the Visual SourceSafe database records and tracks item information that is unavailable for file-oriented systems. Whenever the file is added, modified, shared, moved, or from the project to delete, Visual SourceSafe will simultaneously update the history of files and projects. You can apply project history to simplify these work: Browse to specify the status of all files in the specified project and its total sub-projects prior to. • Repairing changes information that may cause a specified file that may cause the error on a certain date. Re-generate the previous version of all applications. Maintain the source file shared by many different applications. Determine which item will be affected by the file being shared by multiple different applications. Manage specific customer versions of the general application. For software developers, trying to accomplish these jobs through file-oriented systems, will be unbearable trivial and no benefit. As explained in the following scenarios, Visual SourceSafe's project-oriented version control will be wireline the development process. For the consecutive preparation, you will have a primary application that contains many separate parts.
Before you start a series, you want to confirm that no one is modifying the code in the last time, and during the version control, there is no file to be checked out. A standard version control system is provided to you a tool that determines if a file is checked out. Your job is to run the tool for each file that will be used to compile. Although the introduction of batch files and wildcards will make tasks simple, it is still very cumbersome when faced a complex system. As in other systems, Visual SourceSafe can determine if a file is checked out. But it can also create a high-level report: a list of all check-out files in an item. This feature is especially strong when cycling in the current project. Visual SourceSafe Checks each file in each related project and generates a list of check-out files. You can immediately know if you can make a series (or if you can't find anyone). Only one command is required in the project file, Visual SourceSafe can automatically complete the previously long-handed work. Accurate regression includes all version control systems, including Visual SourceSafe, have file history reports. History report lists the files from the latest to the oldest version of each file, the file contains information such as what actions, who does what and when finished was what Remarks and other information. Although the file history is very useful, they also have some defects. For example, assuming a feature can work normally last week, but the problem has been issued in this week. Obviously, someone has introduced this error recently, but in which file? In the standard version control system to solve this problem, you need to generate a history report for a file like a wrong, see if it has been modified and browsing the modification. If you don't find an error, you have to select another file to check, so push. You may use this method to find all the files in the system but have not found key modifications - because in fact this modification is an increase or deleting file, and the standard version control system does not track such an action! In Visual SourceSafe, you generate reports through the project itself. For example, it may report that Common.bas is just modified; before this, OpenAll.frm is modified; before, FileSupp.bas is added to the project; Visual SourceSafe finishing these otherwise you will manually complete the retrieval modification information, allowing you to browse all the modifications of the last week. This will save you a lot of time and help you avoid caught in trouble. Recreate the previous project version by retrieving the history of the project, Visual SourceSafe allows you to quickly recreate the previous version of the entire application. This will help you solve the error reported in the previous version and confirm that they have resolved in the currently developed version. For example, it is assumed that one user report version 2.03 has a print problem. The version of the application may contain a file version 10, another file version is 15, so you don't have to worry about it. Request a specified project version from the Visual SourceSafe, you can restore a list of local copies of the application source file for the 2.03 version of the application source file. If you apply the standard version control system, you or you must independently archive the source of each release of your application or you need to search for each version of the file. In both methods, it is an annoying manual process for the previous context of recovering the correct source file - a work that may be canceled or postponed. Maintenance Reusable code Most applications are developed on the basis of a public core code. These files have been used again and again in many different applications and have been constantly improved, and the error repair, performance improvement, and new features.
