SVN version control

SCM software version control management, commonly used tools: CVS, SVN

SVN sub-server and client

Server :
　　server establishment: three steps
　　Step 1: Build a core warehouse, repository
　　Cmd console: Svnadmin+create + name
　　Step 2 : Setup Permissions: svnserver, the name and password in password Step
　　3 : Start the server: svnserve -d-r+directory name/relative path.
　　Note: The console window cannot be closed in this way, otherwise the server will be shut down.
　　Two operating modes of the server: 1. svnserve 2.
　　Common functions of apache http client:
　　Download/Update: Update/CheckOut That is, take out the content from the warehouse.
　　Upload/Submit: Commit/CheckIn puts the content into the repository.
　　SVN is mainly used for teamwork and multi-person remote development, so there is a simultaneous problem, which will cause some conflicts. How does SVN handle conflicts?
　　Three methods are usually used:
　　1. Update the remote file to the latest to the local, and then re-add your modifications.
　　2. Abandon your modifications, update the remote ones to you, and use the latest ones.
　　3. Human communication.

1. Version numbering
　　For example , our version library is A, which has files a, b, and c.
　　In SVN, the version number of a new version is not for a specific file, but for the entire library. Submitted 5 times and submitted 6 times, the file a may be different or the same, that is, version 1.0 and version 1.1 may be the same. Because the 6th commit is probably because file b or c was modified. In CVS, on the contrary, each update may only modify the version number of the file, that is, version 1.0 and version 1.1 of a file are definitely different.
　　(To correct a concept here, the statement "the second version of file a" is wrong, it should be "the second modification of file a, that is, the second Commit")
　　SVN's global version number brings SVN Many advantages: If copying a directory or file, no matter how many files are involved, SVN does not need to execute the copy command for a single file in turn, but only needs to create a pointer to the corresponding global version number.
　　2. Directory version control
　　CVS can only perform version control on files, not on directories, which causes CVS to lose many functions:
　　1) There is no move operation
　　in CVS. There is no move (move) operation in CVS. During the move operation, CVS can only notice that a file was deleted in one location and another file was created in a new location. Since it doesn't connect the two operations, it's also easy to lose track of file history. So when using CVS, the location of each file must be chosen carefully.
　　2) There is no rename operation
　　. There is no rename operation in CVS. Renaming files artificially will make the files before and after naming lose the historical connection, and recording history is the main purpose of version management.
　　3) No copy operation
　　There is no copy (copy) operation in CVS. For CVS, artificial copy can only see the increase of new files, but cannot record the connection between the copy source file and the target file.
　　SVN avoids these deficiencies to a large extent, and SVN treats directories as a special kind of files. When subdirectories/files in a directory are deleted, renamed, or new subdirectories/files are created, the contents of the directory will change. Therefore, SVN records the modification history of directories just like the modification history of ordinary files. When a file/directory move, rename or copy operation occurs, SVN can accurately record the historical connection before and after the operation. Similarly, like comparing different historical versions of a file, SVN supports the comparison of different historical versions of a directory, and clearly shows the change history of the directory.
　　3. Atomic submission
　　CVS and SVN are also used as SCM version control management tools. The atomic submission of SVN can be said to be superior!
　　SVN submits a file, and the submission becomes valid only when all file modifications are successfully stored in the repository. Once interrupted, SVN will automatically perform a "rollback" operation. This mechanism of SVN ensures that all modifications are either all stored in the library to take effect, or none of them are stored in the library. Due to the atomic commit feature of SVN and the global version numbering method, when the commit is successfully completed, a unique and new global version number is generated, and the log information provided by the user at the time of commit is associated with the new version number, and is only stored once (Different from CVS's repeated storage by file).

In the basics, we briefly talked about how to use SVN, but most of them are operated under non-visualized conditions, which is difficult for most of our students. If there is an uncomfortable place, there must be a good alternative. Today I will introduce the use of visual SVN to you.

　　VisualSVN is a plug-in for VisualStudio. Through Visual SVN, we can manage SVN code in VS. Right-click on the corresponding project or class in the project explorer, and you can see Update (update) and Commit (commit), which can be done here. Complete the corresponding tasks.

　　VisualSVNServer is a server-side visualization. We can see the files in the server.

　　You only need to know that one of them is the client side and the other is the server side. The following describes how to use it.

　　Installation will not be introduced, all the way to Next installation.

　　We said above that VisualSVN is a plug-in for VS, so of course we have to find him in VS!

　　The server can be found in our start menu.

　　We first open the server, let's get to know it:

　　the first is the library, which we have introduced in the previous article. Then the user is to register the person who uses this library. As for the group, it has not been used yet. It is used to separate people from different groups for large-scale projects. In fact, whether it is a user or a group, it is to allow specific people to have specific permissions to access or modify a file in the library.

　　The following is the construction of the repository:

　　right-click to see Create New Repository, click to create the repository. Enter the library name, OK. The library is basically built successfully! how about it? Much simpler than the method introduced last time.

　The library is established, let's add users:

　In the same step, right-click on Users to Create New User. Enter username and password. can be added successfully.

　　The library has also been built, and the user has also added it. Is our task completed? The important thing has not been said, permissions!

　　Permission is like a kind of certificate, you can only do things within your authority, otherwise it will be messed up? Just imagine, if we cooperate in development and everyone can submit it, this part was originally made by me, but you accidentally changed it for me and submitted it to the server, so wouldn't our two things conflict?

　　Therefore, when creating a user, different permissions should be assigned to the user according to the specific tasks of the user. Taking a simple three-layer as an example, test1 is responsible for the UI layer, so the permission of test1 can only submit the UI layer, but he cannot submit BLL/DAL. The update is open to all users.

　　Let's see how to configure permissions.

　　First of all, let me explain that setting permissions is the permissions of a user to a library, so it is a property setting of the library.

　　Right-click the library name, click Properties, and click Add to add the user to the library's properties.

　　I believe everyone has seen the Permissions below him. Select the user to select the appropriate permissions.

　　Read/Write read and write permissions.

　　ReadOnly read-only permission.

　　No Access, not allowed, that is, no permission.

　　Inherit fromParent, inherited from the parent. What's the meaning? The parent here refers to the parent of the library or the file in the library, that is, which library the file belongs to, and the user's permission to the file inherits the user's permission to the library. That is, what permissions the user has on the parent of the file has any permissions on it.

　　Now I have a special feeling about the permission part. Before development, each user should be required to change only the part of the code they are responsible for, and the rest can be viewed but cannot be changed. What if it really needs to be changed? 1. Take out a backup and change it. 2. Notify the colleague in charge of this part, let him change it, and only update it yourself. In this way, conflicts can be avoided and the efficiency of cooperation can be improved.


http://blog.csdn.net/annkey123/article/details/8161270