Have a question about the SVN branch, hope you can get help?

Here's how to set up a branch:

1. Check out the files or folders in the archive to be organized and modified.

2. Right-click on the checked out file or folder, move the mouse to "tortoisesvn" in the pop-up menu, then select "Branch Marker", type the path name of the folder you want to create a branch in the pop-up Branch Tag dialog box, and fill in the log information.

3. Click OK to complete the creation of the branch.

4. Right-click on the checked file or folder, move the mouse to "tortoisesvn" in the pop-up menu, then select "Switch", type the name of the folder path where the branch was created in step 2 in the pop-up Switch to branch tag dialog box, and click "OK" to complete the switch.

If two people change the same version of the same file, the latter person will definitely be prompted to find a conflict when committing or updating, and similarly with branch merge, a conflict will be found.

SVN branch merging is simply a matter of taking a version of a folder you specify in the SVN repository and comparing it with a local folder you specify, and then transferring the difference to your local folder.

Regarding the use of branch merging, for example, according to the official recommendation of SVN, the root directory of an SVN repository will be divided into three subfolders: trunk, branches, and tags. Among them, trunk is used to store the ** that is constantly added, modified, and committed. When the development reaches a certain level and a round of testing is required, in order to avoid mutual interference between development and test bug fixing, pull a branch from the trunk (copy a current image) to the test001 folder under branches, and all defect fixes are modified and committed in the test001 folder under branches.

When this round of testing and bug fixes are completed, and then all the changes in the test001 folder are merged into the trunk, then the branch merge function completes the following things: compare the latest version of the test001 folder on the SVN server with your local client trunk folder, if there is no conflict, overwrite the modified files in test001 to the corresponding files in your local client trunk, and then perform the commit operation by yourself again. If a conflict is found, a conflict has occurred and the merge has failed.

Now that you understand what the branch merge function does, I think you will understand the difference between it and commit update.

Branches are developed in parallel, and merging is the combination of branches developed in parallel into a whole. The trunk is the root of the branch.

Branch merging is done for the needs of the project, not for every project. SVN tools are not difficult, the difficulty is to master the concept of configuration management, it is recommended that you can be familiar with the knowledge of configuration management first, SVN is just a tool to implement configuration management.

You didn't mention the folder structure of the "LAN Development Environment" in the diagram, and that's the point.

I understand that the problem you have should be this: multiple versions of the software are being developed or maintained at the same time, but the multiple versions are stored in the same folder on the server, resulting in conflicts.

If that's the case, I'd recommend that you make reasonable use of SVN's branching feature. Let me describe the plan for SVN in a multi-version simultaneous development environment

1. According to the official advice of SVN, create 3 folders in the root directory of the repository: trunk, branches, and tags.

2. The trunk folder is the backbone of the development, where the latest version of the development results are stored, and the content here is unstable, even untested, and changes frequently.

3. Branches is to store each branch, whenever you want to form a relatively stable beta version, pull out a branch (svn copy) from the trunk to the branches, for example, branches will form multiple subfolders such as versions, versions, versions, versions, etc., and then deploy the test environment to get ** from these folders, and the repair of bugs found during the test is also carried out in these branch folders, and at the same time, the development on the trunk is carried out normally. The two sides do not interfere with each other.

4. When the test is completed and it is officially released, it will be pulled from this branch to the tags, and the tags will store the official release version of each version, which will form multiple folders.

5. When it is necessary to apply a fix in a beta version to other versions or trunks, merge between different branches under branches or between branches and trunks, and the merger may cause conflicts, and the conflict will be resolved at this time.

6. In this way, the latest version development is always carried out in the trunk, the test and repair of a certain version or the maintenance of the previous version are carried out in the subfolder of the version under branches, and the official version to be released is always obtained from tags, and the whole library is in order.

If you create a repository called main, then main is the root directory of this repository, then all branch operations can only be carried out under main, if you want to be parallel to main, it can only be another repository, there is no direct relationship with main, and the historical relationship cannot be tracked.

Generally speaking, the official repository directory structure recommended by SVN is as follows: first create three folders of trunk, branches, and tags in the root directory, and the normal development work is carried out in the trunk folder, branches are used to store branches, and tags are used to store version tags.

It is recommended that you do this, create trunk, branches, and tags under main, and then move the content you originally placed in the trunk folder to the trunk folder (not with the copy and paste operation of the operating system, but the move operation of svn, otherwise the modification history will be lost), and the development will be carried out under the trunk in the future, and when you want to make major modifications, pull a branch to the branches (the permission is set to read and write to the modifiers, Read-only for other personnel), pull the branch to tags when you want to release the version (the permission is set to read-only, and only the administrator is configured to read and write).

If everyone is developing on one trunk, A's work is not done, and B can't be debugged at all.

So we need to open a branch to reduce B's dependence on A.

If it is the development of a single project function, there is not much difference. However, if the project is complex or has different functions, it is generally used, for example:

1.Suppose that the ** in your A library is to release a lot of different software to different users, and these user functions are very different, at this time you will find that some of the main ** are common, differentiated** is relatively few, in order to facilitate management and development, you can use the branch development method at this time.

Each branch develops and releases a version, and the same [core**] changes are merged into the trunk for people in other branches,,, this is just an example, and others may also use this method.

2.Trunk development is generally basically the same function, and it is easy to trace the problem when it is released, and the trunk branch exists in a project at the same time, not to say that it is only used for a single purpose.

To put it simply, SVN is a DU version management software based on the CS architecture.

zhi, be able to help.

DAO you save each version of the development process.

In fact, to put it simply, SVN is a management tool, managing ** ah documents and other work products, SVN with history traceability function, can know all the historical information you have from scratch.