A little understanding of tag,branch,merge in software version management such as CVS,SVN

For the project development process, the following situations occur:
(1) For a project to develop a certain stage, decided to release an initial version of V1.0;
(2) V1.0 version on-line, for the project continue to develop (may add new features, feature upgrades and other upgrades to V2.0), at this time the original code has been changed;
(3) At this time in the V1.0 found a bug, need to change immediately, or need to urgently add a feature in the V1.0, need to modify the source code.
There is no version control, this time the trouble comes. Consider a primitive way (as you did when you went to school):
(1) Start copying a folder to the V1.0 version of the project as a backup;
(2) for the new version began to develop on the V1.0, this time the code may have changed very much;
(3) Need for V1.0 modification, then copy a directory for the original V1.0 backup code, modify the bug, to add a feature;
(4) When the code for V1.0 is modified, to the development of the V2.0 version, at this time, if the two sides of the code to merge together, that is: for the V1.0 bug, emergency features are also changed to V2.0;
(5) Ctrl + C, CTRL + V, deletion code, hehe ... Chaotic ..... Basically, there is no doubt that this will lead to inconsistent code.

With CVS, SVN, etc., you can manage:
(1) for the V1.0 development completed, carried on the line. At this time, for this version using "tag" tag-v1.0_release, "tag" is a snapshot of the code point in time (can not be modified on the snapshot);
(2) Continue the development of V2.0 code;
(3) Need to modify the original V1.0 code, at this time through the tag tag to get the time of the code snapshot (if the modification at this time, and then commit to submit an error, not directly on the tag version of the modification);
(4) based on the tag version, establish Branch program branch, as V1.0_RELEASE_R1;
(5) in the V1.0_RELEASE_R1 branch to modify the bug, to increase the emergency characteristics;
(6) in the original V2.0 code in parallel development, at this time both sides can be simultaneously;
(7) V1.0_release_r1 for the bug and other processing completed, released, as V1.1 on-line;
(8) At this time originally in the V1.0_RELEASE_R1 modified bug, in the V2.0, still exist, and then "Merge", increased to V2.0;
(9) OK. It's over.

Write it casually. Oh