Experiences in using SVN

The previous blog briefly introduced the preparation for using SVN in cooperative development projects. This blog focuses on usage specifications, precautions, and rules. let's talk about his little experience!

Prior to the start of the Cooperative Development Project, Dr. Jia Lin proposed to us the svn usage specification as follows:

SVN requirements (very important ):

1. The program needs to be compiled regularly and uploaded to SVN. It can be uploaded multiple times a day and determined based on the individual program development progress, however, you must compile and debug the program of the day and upload it to SVN before getting off work every day.

2. Update the latest SVN version before going to work every morning.

3. When adding pages, deleting pages, and modifying page names in a program, you must first update all programs, especially solution files, and then add or delete pages and modify page names, after completing these operations, you need to upload SVN immediately to avoid solution conflicts.

 

The following files cannot be submitted to SVN. They should be added to the ignore list locally through the svn client.

1. suo file of the Solution

2. Bin folder and OBJ file of the project

 

I saw it for the first time and didn't pay much attention to it. However, we were using it. The version was not described and there was a conflict between cooperation, A self-developed module affects other people's modules. it is very important to look back at the content. I will explain and complete the details here!

 

First of all, we have developed cooperation in the company, and SVN is widely used in the company. Even if it is not the software I mentioned above, it is also a very similar version management software. by using SVN, we assume that we have all the problems from the perspective of company members.

I. The program is regularly compiled and uploaded to SVN, that is, the Program on the server we uploaded must be able to run normally. Do not paralyze the entire program and affect everyone's work by modifying the module by yourself. to upload the svn server, follow these steps:

Why must I upload the compiled program tomorrow night?

1. In the company, you can first let the project manager know that he is working every day and his progress;

2. Secondly, we can avoid the loss of backups;

3. In addition, we can avoid making too many changes. if a conflict is difficult to solve!

 

2. Update the latest version every morning. This is an effective way to avoid conflicts!

3. The third point is very important, that is, when adding pages, deleting pages, and modifying page names, We need to update the solution first, then perform the above operations, and then upload them immediately. Remember to do it right away.

Why? This involves a file with the extension. csproj. Let's take a look at the Encyclopedia:

C # the extension of the project file. It is short for "C sharpproject .. When a project is created in the. NET development environment. csproj file, which is a project file of C #, which records information related to the project, such as the file contained, the version of the program, the type and location of the generated file.

 

That is to say, one project is one. the csproj file, because although we work clearly in the development phase, each of them is responsible for their respective modules, but when we do the above several operations, we will modify this file. If both of them perform this operation during the upload process, the next upload will conflict, and the conflict must be resolved. This is troublesome. We update the file first, modify it, And then upload the file immediately to minimize the chance of sending a conflict.

 

4. Why not upload the. suo file,. binfile, And. OBJ file? Let's take a look at the functions of these files:

1. suo (solution user options) is a file format. *. Suo solution user options, which record all options that will be associated with the solution, so that each time you open it, it contains the User-Defined settings. The vs layout includes the Variable list of monitor 1234, the breakpoint mark and switch status, the distribution of the error window in the output window, the floating status, and the project unload status mark.

That is to say, the Suo file records the user's settings for the solution, so that the next time you open the file, it will better meet the user's habits. Of course, if it is deleted, the solution will be re-established when the solution is opened, except for the break points of the records, and the layout of various windows will not be available. Therefore, we do not need to upload the. suo file and generate it locally.

2. Bin and OBJ files:

There are also some DLL files in the OBJ file, and these DLL files are generated by the project,

That is to say, the content in these two files can be generated through the solution. Of course, you do not need to upload the files. We can download the files to the local directory and generate these two folders locally.

 

In this way, you will understand why you do not need to upload these three files. For the conflicts mentioned above, I would like to explain the solution to the conflicts:

If two people conflict with each other and prove that you have modified one or more files at the same time, you must sacrifice one person's achievements, upload another person's results to the latest version (through negotiation ). Of course, the sacrifice does not mean he cannot find it. First, he can keep the backup in advance, modify it when it can be updated to the latest version, and then upload it. Of course, we can find any version in SVN, download it, modify it, or view previous functions. Below is our version update, with no logs added in the red box, so we don't know what this version was changed.

Although the conflict can be solved, it can be avoided as much as possible. After all, it is quite troublesome.

 

To sum up the experience of using SVN, I will mainly elaborate on the svn specifications given by Jia Linge. If you have any questions, please contact us!