| Summary Professional Software development requires thatProgramOfSource codeManagement of modifications for pipeline processing. Microsoft _ visual sourcesafe? Records the history of system, project, and file-level modifications, allowing you to securely allocate development work among multiple programmers and track changes, and restore the early versions of individual files or the entire application. Introduction CodeIs a valuable resource. To protect it, many developers apply some version control systems to protect files from unauthorized modifications and unexpected errors. There are many types of systems, from changes to program comments and the storage of old gentleman agreements to complex software systems that automatically track changes and historical records. Most source control systems are effective for separate source files. However, almost all of them cannot establish relationships between files. This will cause problems in Microsoft Windows, because in this environment, an application can contain multiple executable files and dynamic connection libraries created by many different source files, they may be used repeatedly in many other applications. Today, managing the relationship between source files is equally important as protecting the content of source files. Microsoft Visual sourcesafe version control software solves this problem by combining project management tasks with source code control. Visual sourcesafe provides an excellent solution to this problem, which is not easily implemented by a standard file-oriented source control system. Software development pipeline To understand the advantages of project-oriented source control, you only need to compare it with a file-oriented system. A standard version control system (for example, the Unix tool RCs) must be a set of tools used to operate independent files, control file access and update, and compare with earlier versions. To operate a group of files, you need to write a batch file or specify wildcards in the command line. Microsoft Visual sourcesafe stores files in the central database of the network, rather than in a common dos directory. At the system level, the database is represented as a "black box ". However, when visual sourcesafe is used as the view, you can see that the database contains all the source files and history records from your organization to the project hierarchy. When you retrieve a file, visual sourcesafe marks the file as checked out in the database and allows you to modify the file on your machine. When you put the file back, visual sourcesafe updates its database and re-modifies your machine's access permission to the file to read-only. However, what is the difference between this and file-oriented source control? For each change, the visual sourcesafe database records and tracks project information that is unavailable to file-oriented systems. Each time a file is added, modified, shared, moved, or deleted from a project, visual sourcesafe updates both the file and project history. You can use the project history to simplify these tasks: View the status of all files in a specified project and all its sub-projects before the connection. ? Narrow down the changes to the specified file that may cause errors due to the joint compilation on a certain date. Regenerate the previous version of all applications. Maintain the source files shared by many different applications. Determine which project will be affected by changes to files shared by multiple different applications. Manage specific customer versions of common applications. For software developers, attempting to do this through a file-oriented system is unacceptable and trivial. As described in the following scheme, visual sourcesafe automates the development process by directly implementing project-oriented version control. Prepare for connection Assume that you are concatenating a master application that contains many independent components. Before you start, you want to confirm that no one has modified the code at the last moment and that no file is checked out in the entire system during version control. A standard version control system provides you with a tool to determine whether a file is checked out. Your job is to run the tool on every file in every directory that will be used for connection. Although the introduction of batch processing files and wildcards will make the task easier, it is still very cumbersome in the face of a complex system. As in other systems, visual sourcesafe can determine whether a file is checked out. However, it can also create a high-level report: a list of all checked-out files in a project. This feature is especially powerful when the current project contains all sub-projects cyclically. Visual sourcesafe checks every file in each related project and generates a list of checked-out files. You can immediately know whether you can establish connections (or who you should look for if you cannot ). You only need to execute a command in the project file, visual sourcesafe can automatically complete the previous lengthy work that needs to be done manually. Exact Regression All version control systems, including visual sourcesafe, have file history reports. The file history report lists each file version from the latest to the oldest, including operations on the file and who performed the file, information such as when to complete and what remarks are made. Although file history is very useful, they also have some defects. For example, assume that a feature can still work normally in the last week, but there is a problem connecting your application this week. Apparently, this error has been introduced recently, but in which file? To solve this problem in the standard version control system, you need to generate a historical record report for a file that appears to have an error, check whether it has been modified recently, and view the modification. If no error is found, select another file for check, and so on. You may have used this method to search all the files in the system but have not found any key changes-because in fact, this change adds or deletes files, the standard version control system does not track such operations at all! In visual sourcesafe, you generate reports through the project itself. For example, it may report that common. Bas has just been modified; before that, openall. frm has been modified; before that, filesupp. Bas has been added to the project; and so on. Visual sourcesafe sorts out the changes that you will manually retrieve and allows you to view the order of all changes in the last week. This will save you a lot of time and help you avoid getting into trouble. Recreate the previous project version By retrieving project history, visual sourcesafe allows you to quickly recreate the previous version of the entire application. This will help you solve the errors reported in the previous version and confirm that they have been resolved in the new version currently being developed. For example, assume that a user reports a printing problem in application version 2.03. This version of the application may contain a file version of 10 and another file version of 15, and so on; but you don't have to worry about this. Request a specified project version from visual sourcesafe, And you can restore a complete local copy of the application source file used to connect to version 2.03. If the standard version control system is used to complete these tasks, you must either independently archive the source of each release version of the application or search for a specified file for each version. In the two methods, it is an annoying manual process to restore the correct source file for the previous connection-a job that may be canceled or delayed. Maintenance reusable code Most applications are developed based on a public core code. These files have been used again and again in many different applications and are constantly improved over time to get bug fixes, performance improvements, and new features. The benefits of applying existing code are enormous, but it is still a headache for handling organizational issues. You must remember which applications use the file and send each modification information to all appropriate places. When five applications reuse one file, this is only a small hassle. When 20 applications are mixed together and match 50 different reuse files, this is troublesome. A standard version control system cannot help with this problem, because a source file can exist in multiple different projects at the same time. However, visual sourcesafe can do this automatically. In its database, visual sourcesafe stores each file only once. Each project file contains a file with a pointer to the file location in the database. For each project, all versions of files are available. At the same time, a project can "freeze" the version of a file to avoid introducing errors when other development teams work on reusable code. To give a general example, assume that you have a source file that contains multiple different print report processes. In visual sourcesafe, each application that needs to print the report needs to share the file. If you find an error, you can update the file from any project-this change will be immediately transmitted to every project that shares the file. Visual sourcesafe can report which projects share the file, so you will know which applications are affected and need to be re-connected. Create a specific user version Another common source control issue is about users who want to customize applications to meet their specific needs. Originally, you have many different applications that share almost all the same source files. Applying standard source control tools will take more time than programming to track errors and maintain continuity. With visual sourcesafe, you create a project for each new user to specify which files are shared and which files are exclusive. When you work in a project, changes to specific users will be kept in the current project, and modifications to shared files will be transmitted to all user versions. |
