In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.
I’m out there helping that adoption so I’m a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. If you have any other strategy, I would like to hear about that. It pretty much depends on your unique development environment. Ideally, you do not merge from trunk to the tag.įinally, remember that there is no ideal branching and merging strategy.
SUBVERSION BEST PRACTICE PATCH
This will come in handy if a very minor patch has to be made on the release version when your trunk is temporarily dirty. I always use Tags to tag a release whenever a new release version is deployed. When you create a branch simply rename the folder from branch/branches to tag. When the developer branch or feature branch is ready for release, merge changes back from the branch to trunk. Because, after a couple of days conflict between trunk version and branch version can get out of hand and merging will practically be impossible. It is always beneficial to merge changes from trunk frequently. It is the responsibility of the team lead to merge changes from trunk to this feature branch on a regular basis. It is the responsibility of the developer to regularly (timeframe depends on your development environment) merge changes from trunk to his branch.Ĭreate a feature branch if 2 or more developers are going to work on a new feature that will take considerable time to complete.
SUBVERSION BEST PRACTICE CODE
Branch:Įach developer must create his or her own branch if their code will take more time to program than your normal deployment cycle. If it takes more than 2 days, they are not allowed to directly change the code in the trunk.
Any developer making changes to the trunk must be absolutely certain that his or her part can be coded, tested and is ready to deploy within 2 days (can vary depending on your length of deployment cycle). The code in trunk is always maintained as close to release state as possible. Trunk, branch, and tag are the 3 main divisions in subversion repository. With a team of 10 developers it will be a nightmare in the absence of a proper branching strategy. Meanwhile, simple modifications and patches are requested on a day to day basis in the Version 1.0.0.0.Įssentially, with the changing business needs you are required to do a deployment every other day or so i.e. You envision it will take couple of weeks to get that feature coded, tested and released. Couple of days after the release, you get a request for a new feature that must go as Version 1.1.0.0. Let us assume that on a day to day basis you use agile methodologies such as extreme programming or scrum and you have finally released a reasonably complex project with Version 1.0.0.0. You may need to adopt branching in many different scenarios. This blog aims to provide a simple branching and merging strategy to manage the code in a fast paced team development environment.
SUBVERSION BEST PRACTICE SOFTWARE
Version control systems play a vital role in the success of a software development team. 4 FAQ on SVN Branching and Merging Strategy
0 kommentar(er)
