SVN Version Control Considerations

As a student, there are often two or three people together to complete the development of a software, everyone modify, add, delete their own code on the local hard disk, when they put these codes Taken together, the work summarized need to be very careful, this is just a small team of two or three people. When a small team we GIT or SVN basic functions can help us to do version control, you do not need to create and merge branches. In the workplace, we often release while the development side, the iteration will be very frequent, there is often a new feature development to half, broke the old function to repair Bug. Then you have first hand the code to the repository, and then switch to the old branch to join the Bug repair work. Here it is inevitable to meet to discuss the GIT and SVN, I'm actually more respected in the workplace SVN, discuss this topic at a student, there are people jump out, talking maverick, saying what SVN centralized version control It is to stifle good programmers like words. Indeed SVN version control each submission must worry Conflict, it will certainly affect the efficiency, then why even behind the SVN version control it?


In six months time for PM's job, SVN and GIT I have used the depth, in short, more suitable for project management SVN, Git applicable open source project code management. SVN said earlier, each submission must be checked Conflict, which just ensures that the code can always track is conducive to performance assessment, such as tracking (by whom and when to come in the introduction), while a security code on SVN Bug is how arise have done well, SVN can be controlled by a sub-directory permissions for individuals. Distinguish read for everyone, write permission. More stringent, do not support the rollback operation. In contrast Git is no strict rights management control, as long as the account, you can export, import code, or even execute a fallback operation.


There are conventional SVN repository directory structure three folders:
Trunk
Tags
branches

Which, trunk (trunk | mainline) branchs (branch) tags (tag).
trunk (trunk | main | main branch): is used to deal with the release, when the module development is complete, then merge from branch to trunk.
branch (branch): branch and main line of development is the development can be carried out at the same time, but this is not recommended, the branch is world developers, trunk PM is the world.
tag (mark): used to mark one of the available versions, can be marked on the line has released version, you can also mark the version being tested, usually read-only.


Note:
1. The only branch to trunk closer (merge), not vice versa!
2. open a branch responsible for the development of new features, after testing by the PM responsible merge into the trunk.
3. The branch is responsible for bug fixes for the current release (to be developed can be placed in the next release of improved version of the bug directly on the trunk)
4. Modify the bug on the branch, regularly merge to the trunk, try to merge in time (to avoid a large area of conflict)!
5. until the next new version is released, the branch stopped modification.

---------------------------------------------------------------------------------------------------------

 

 主干(trunk)
    |
    | --------------------->>>| 分支A -------V1.0发布----->  客
    |                                                       户
    | <<--merge--- | ---------| ---bug修正发布V1.0.1------>  部
    |                         |                             署
    |                         |                             环
    | <<--merge--- | ---------  ----bug修正发布V1.0.2----->  境
    |
    |
    |
    | --------------------->>>| 分支B -------新功能加入--->  内
    |                                                       测
    | <<--merge--- | ---------| ---新功能测试通过--------->  部
    |                         |                             署
    |                         |                             环
    | <<--merge--- | ---------| ---又一个新功能测试通过-----> 境        
    |                         |
    |                         |
    |                         |
    |(直至发布V2.0停止V1.0的修正,若V2.0上线遇到问题,快速回滚到V1.0最新修正版本)

---------------------------------------------------------------------------------------------------------

Extended:
Use SVN to do Merge operation, it contains six options, the following detailed description is given on these six options:

1.Merge a range of revisions
of this type most widely used, mainly to modify the source branch target branch up to merge.

Fill merge source URL is the URL to merge source branch, version range to be merged If empty, it means that all versions of the merging branches, namely the branch since evolved to create all of the latest version of the current branch.
If you choose just one version, then that version represents just choose to modify, amend, before or after will not be accepted.

2, Reintegrate a branch (regression fusion)
can be understood as a first type of merger of a special case, i.e. the branches directly modify the source file on the target covering the respective branch. The combined results will enable the branch and trunk exactly the same, so you can delete the branch.
 
3, change-set based merge (Collabnet need to download software)

4. Merge two different trees
of this type the first two types, a first type may be selected source branch merged version, branch target can not be selected version;
second type branch source and destination is not selected branches merged version; and this is the type of either the source or target branch branches can choose to merge versions,
which can choose a version of a target branch version of the past are combined with the source branch. When combined with the branch-based version of the source selection,
if you select the source and target branch version has a different version of the local branch, the branch target will be to give up part of consolidation.

Starting URL: Select the URL of the target branch of the directory (URL should be consistent with the current working copy, this is called the merge point)

The end of the URL: Select to merge source branch of the URL.

Start and end version: general should find initial version version when the last sync, if not from the synchronized (first consolidation), then select the version of creating a branch,
the end of the general version is the latest version, if you do not want some content will be merged into the trunk, you can also select a merge point.

5.Manually record merge information (not need to manually specify the combined modified)

6.Manually remove merge information (manually specify the changes to merge)

References: https: //blog.csdn.net/vbirdbest/article/details/51122637   

Published 105 original articles · won praise 177 · views 260 000 +

Guess you like

Origin blog.csdn.net/ai_64/article/details/104826005