Analysis of development mode process based on SVN branch

In the use of svn The general working mode of multi person collaborative development is as follows ：

Check out Library Create and maintain development branches Merge the trunk code back into branches on a regular basis , Ensure data integrity , Avoid conflicts when merging back to the trunk Branch test Merge branches back into the trunk Trunk submit 、 Deploy When many people work together , The third step is the most common problem , Seriously, it may even cause the code to be overwritten and rolled back , The reason is that the branch manager no longer pulls back data from the trunk or for a long time after creating a branch , As a result, the file and even structure of the branch are quite different from that of the trunk when it is finally merged back to the trunk , Generate more conflicts . It needs to be solved manually , A lot of time was wasted .

In response to this question , Is there a scheme to detect whether the last merged version of the branch is consistent with the trunk version when the branch is submitted , If not, it is not allowed to submit , Force everyone to form the habit of pulling data from the trunk ？ If it can be achieved , Then the conflict will almost be eliminated when the branches merge back to the trunk .

The current thinking mainly includes 3 Kind of ：

1. Do not emphasize the use SVN Always synchronize code from the trunk to the branch . The disadvantages of this scheme are obvious , Rely entirely on labor , Unbelievable .

2. stay trunk There is a separate one with the latest version number in readme.md, Each update trunk Update this version to the updated version number . After that, when merging and branching back to the trunk, judge the next branch readme.md Whether it is connected with that in the trunk readme.md bring into correspondence with , If it is smaller than the trunk , Force synchronization of trunk code to branch . The disadvantage of this scheme is that the version number needs to be manually maintained every time the trunk code is updated , Prone to low-level errors —— to update trunk Forget to update when readme.md Version number in .

3. SVN It records version update information , It can be done by The server End monitoring backbone , Judge before submitting (pre-commit) Check whether the last merged version number of branches is less than the trunk version number , If it is less than, it is not allowed to submit , It is mandatory to merge from the trunk first . This scheme is a relatively perfect scheme .