Overview
This is the second article in the Product Development Management series: Using Subversion for code management.
There is a lot of information about how to use subversion, and there is no way to describe how to use subversion. This article focuses on how to manage code versioning.
Using Subversion for code management
The starting time for
- time Point (1)
- (1) is the beginning of 3.0 development.
- during (1), no user was using 3.0 (because it was not yet published), so all developers developed directly on the 3.0Trunk. The end time for
- (1) is the end time of 3.0 development. At the end, Release 3.0 products, create 3.0 Tag on SVN, and create 3.1 F000 Branch. Then 3.0 trunk automatically becomes 3.1 trunk. The starting time for
- time Point (2)
- (2) is the beginning of 3.1 development.
- during (2), 3.1 of all developer development work is done on 3.1 F000 branch because the user installation started with 3.0.
- If during (2), the user reports a 3.0 bug and needs to be repaired immediately. Then:
- Fix the problem on the 3.1 trunk and release the Fix Pack. The
- merges this change onto the 3.1 F000 branch. The end time for
- (2) is the end time for 3.1 F000 development. Released 3.1 F000 product at the end. At this point, do the following:
- before merging the code, create a tag on the 3.1 trunk, such as: 3.0 20150601. Used to represent the code before the 3.1 F000 is merged in.
- merges the code for 3.1 F000 branch onto the 3.1 trunk. and lock the 3.1 F000 code to avoid any further modifications.
- creates 3.1 M010 Branch from the 3.1 trunk for development of 3.1 M010.
- Point in Time (3), (4), (5) and (6)
- Basic and point in time (2).
- (5) is the beginning of 3.2.
Note:
1. (5) is the beginning of 3.2, it and (3), (4) The mode of operation is not fundamentally different, but some small distinction, mainly to arrange different types of changes.
In general, we put a relatively large function/change into a new version inside. (3) and (4) as (2) upgrade, mainly responsible for repairing 3.1 bugs and minor feature improvements. Put a relatively large function or relatively low-level changes in the 3.2 inside, that is (5) inside.
2. How many m0x0 are determined by the product manager based on user feedback questions and the list of needs to be developed.
3. Before the start of an iterative cycle, the requirements are gathered in place. The iteration period we use is 2 months, including requirements discussion, design development, testing.
Precautions
According to our use of the situation, there are the following considerations:
- If you fix a bug, you can do it on a trunk or branch, but be sure to use Subversion's merge function instead of changing it two times on the trunk and branch. If you change it two times, the result is a conflict when you want to merge the branch into the trunk.
- It is not always appropriate to make any kind of change. For example, some core data structure changes, put it in the minor version after the first iteration of the upgrade. This big change is a good time to avoid upgrading users, or users need to reload all the data.
- At the end of the iterative development is published on the branch, but maintenance is maintained on the trunk after merging the branch code into the trunk. You need to be very careful when merging your code to ensure that the code on the branch is as critical as the code of the trunk after merging. If this is not the case: there is no problem with the first product released from Branch, and later, in order to fix a bug, a patch pack was released from the trunk, and there was a problem with the first release.
Product development Management (II): Using Subversion for code management
