SVN Article 1-Getting Started Guide

Abstract: Trunk stores the main code, without modifying it. Branch, tag, and milestone are derived from trunk. Branch copies the code in trunk for development. tags are used to store important releases and release version code and bug-fix version code snapshots. milestone should be an important tag. see Part 1 of the workflow.
1. Brief Introduction
The so-called tag or release is a special version, because this version may be of special significance. For example, this version is a special version provided by milestone or release to the customer. In fact, the tag and release practices are exactly the same as branch. Only branch may need merge back to the original trunk, while most of tag and release do not need merge back to the trunk. For example, today we have a trunk version, which is regarded as version 1.0 of the software. Version 1.0 is a very important milestone for development. So we need to make a tag for him. Assume that this version 1.0 is to officially release the version to the customer or the relevant vendor, and we want to make a release tag for it. 2 Concepts
-- TrunkTrunk is the main environment for storing stable code, just like a car factory that assembles finished car parts together. The following describes how to use SVN trunk:
 
 

  
  
Unless you have to handle bugs that are easy to solve quickly, or you have to add unrelated files (such as media files: images, videos, CSS, etc ), otherwise, do not directly develop in trunk
 
 
 
 

  
  
Do not make too many changes to the previous version because of special requirements. How to Create a branch is required (as described below)
 
 
 
 

  
  
Do not submit some contents that may destroy trunk, such as merging from Branch
 
 
 
 

  
  
If you accidentally break the trunk, bring some cake the next day ("with great responsibilities come... Huge cakes ")
 
 
-- Branches
A branch is a normal copy made from a sub-tree in a SVN repository. Generally, it works like symbolic links on Unix systems, but once you modify some files in a SVN branch, in addition, these modified files develop independently from the copied source files, so we cannot think so. When a branch is completed and it is considered stable enough, it must be merged back to its original copy, that is, if it was originally copied from trunk, it should be returned to trunk, or merged back to its original copied parent-level branch.
The following describes how to use SVN branches:
 
 

  
  
If you need to modify your application or develop a new feature for it, create a new branch from trunk and then develop it based on the new branch.
 
 
 
 

  
  
Unless a new sub-branch must be created from a branch, the new branch must be created from the trunk
 
 
 
 

  
  
When you create a new branch, you should immediately switch over. If you didn't do this, why did you create this branch in the original place?
 
 
-- Tags
On the surface, there is no difference between SVN branches and SVN tags, but there are many differences in concept. In fact, a SVN tags is the "photo of this tree" described above: A trunk or a branch revision named snapshot.
The following describes how to use SVN tags:
 
 

  
  
As a developer, you should never switch to or retrieve it, or submit anything to a SVN tag: a tag is like a "photo". It is not a real thing. tags is only readable, not writable.
 
 
 
 

  
  
In special or special environments, such as: production environment ),? (Staging), test environment (testing), etc., can only be checkout and update from a fixed (fixed) Tag, never commit to a tag.
 
 
 
 

  
  
For the environment mentioned above, you can create the following tags: "production", "staging", "testing", and so on. You can also name tags Based on the software version and project maturity: "1.0.3", "stable", and "latest.
 
 
 
 

  
  
When the trunk is stable and can be released, you must recreate the tags and then update the related environment (production, staging, etc)
 
 
 
 

  
  


 
 
 
 

  
  


 
 
 
 

  
  

 
 
3 Workflow
Assume that you have to add a feature to a project and the project is under version control. You need to complete the following steps:
 
 

  
  
Use SVN checkout or SVN switch to obtain a new working copy (Branch) from the trunk of this project)
 
 
 
 

  
  
Switch to the new branch using SVN
 
 
 
 

  
  
Complete new feature development (of course, do enough tests, including before coding)
 
 
 
 

  
  
Once this feature is complete and stable (submitted), and confirmed by your colleagues, switch to trunk
 
 
 
 

  
  
Merge your branches to your work copy (trunk) and resolve a series of conflicts.
 
 
 
 

  
  
Re-check the Merged Code
 
 
 
 

  
  
If possible, ask your colleagues to review the code you have written and changed)
 
 
 
 

  
  
Copy the merged job to trunk.
 
 
 
 

  
  
If some deployment requires a special environment (such as the generation environment), update the related tag to the revised version you just submitted to trunk.
 
 
 
 

  
  
Use SVN update to deploy to related environments
 
 
 
4. in-depth explanation
Subversion has a standard directory structure.
For example, if the project is proj and the svn address is SVN: // proj/, the standard SVN layout is
SVN: // proj/| +-trunk +-branches +-tags
This is a standard layout. trunk is the main development directory, branches is the branch Development Directory, and tags is the tag archive directory (cannot be modified ). However, SVN does not have a clear specification on how to use these directories, but it is still a habit of users.
There are two methods to use these development directories. I focus more on software products (such as FreeBSD), because the development model of the Internet is completely different.
The first method is to use trunk as the main development directory.
Generally, all of our development is based on trunk. When a version/release development ends (development, testing, documentation, installation program, packaging, etc, the code is frozen (as defined by humans, it can be managed through hooks ). Tag based on the currently frozen code library. When the development task of the next version/stage starts, development continues in trunk.
If you find bugs in the previous release version or urgent functional requirements, and the Development version being developed cannot meet the time requirements, in this case, you need to modify the previous version. The Branch should be developed based on the tag corresponding to the release version.
For example, if you have just released 1.0 and are developing 2.0, You must fix the bug on the basis of 1.0.
Chronological order
1.0 code frozen after development is completed
Tag release1.0 Based on frozen trunk
The directory structure is
SVN: // proj/
+ Trunk/(freeze)
+ Branches/
+ Tags/
+ Tag_release_1.0 (copy from trunk)
Development started in 2.0, and trunk is the development version of 2.0 at this time.
The bug 1.0 is found and needs to be modified. Branch is implemented based on the tag 1.0.
The directory structure is
SVN: // proj/
+ Trunk/(Dev 2.0)
+ Branches/
+ Dev_1.0_bugfix (copy from tag/release_1.0)
+ Tags/
+ Release_1.0 (copy from trunk)
1.0 bugfix development in 1.0 bugfix branch and 2.0 development in trunk
After 1.0 bugfix is complete, perform release based on the branch of dev_1.0_bugfix.
Select the dev_1.0_bugfix branch merge back to trunk as needed (when to perform this operation according to the actual situation)
This is a very standard development model, and many companies adopt this model for development. Trunk is always the main development directory.
The second method is to develop each other in the branch of each release. trunk is only used for release.
In this development mode, trunk does not undertake specific development tasks. At the beginning of a development task of a version/stage, a new Development Branch is created based on the version already release, and develop based on this branch. In the above example, the timing relation is.
1.0 develop and run branch of dev1.0
Directory structure
SVN: // proj/
+ Trunk/(not responsible for development tasks)
+ Branches/
+ Dev_1.0 (copy from trunk)
+ Tags/
1.0 Development completed, merge dev1.0 to trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/
Tag 1.0 based on trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/
+ Tag_release_1.0 (copy from trunk)
1.0 development, develop dev2.0 Branch
Directory structure
SVN: // proj/
+ Trunk/
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Dev_2.0 (for 2.0 development)
+ Tags/
+ Tag_release_1.0 (copy from trunk)
1.0. Fixed bugs directly on the dev1.0 branch.
Reference address:
5 SVN code rollback command
Canceling code modification can be divided into two situations:
 
First case: the change is not submitted (COMMIT ).
In this case, SVN revert can be used to cancel the previous modification.
SVN revert usage:
# SVN revert [-R] Something
Something can be a relative path (directory or file) or an absolute path.
When something is a single file, you can directly SVN revert something. When something is a directory, you need to add the parameter-R (recursive, recursive ), otherwise, only the something directory will be modified.
In this case, you can also use the svn update command to cancel the previous modification, but it is not recommended. Because SVN update will connect to the repository server, it takes time.
Note: SVN revert is inherently dangerous because it aims to discard uncommitted changes. Once you select recovery, subversion cannot retrieve uncommitted changes.
 
Case 2: the change has been committed ).
In this case, use the svn merge command for rollback.
The rollback procedure is as follows:
1. Make sure we get the latest code:
SVN update
Assume that the latest version is 28.
2. Find the exact version number for rollback:
SVN log [something]
Assume that the version number to be rolled back is 25 Based on the svn log. The something here can be a file, directory, or the entire project.
For more details, use SVN diff-r 28:25 [something]
3. Roll Back to version 25:
SVN merge-r 28:25 something
For the sake of insurance, confirm the rollback result again:
SVN diff [something]
Submit if the information is correct.
4. Submit rollback:
SVN commit-M "revert revision from r28 to r25, because ..."
The submitted version is changed to 29.
The preceding operations are summarized as follows:
1. SVN update and SVN log. Find the latest version (latest revision)
2. Find the version number (rollbak revision) You want to roll back)
3. Use SVN merge to roll back and forth: SVN merge-R: something
, Reproduced from: http://www.cnblogs.com/jndream/archive/2012/03/20/2407955.html