SVN branching strategy question

Share URL
 
Ajay Kanse's picture
Ajay Kanse asked on December 15, 2013 - 7:50pm | Replies (2).

This is regarding SVN branching strategy- What is harm in deleting trunk and copying branch to trunk to reflect production code which was delivered from Branch.

It is known that history on trunk will be lost however history on the repository still exist and any file at any revision can be recovered. So what would be issues with deleting trunk and recreating trunk from branch.

Tags: 
configuration management
continuous integration
deployment
version control
svn
trunk
branching strategy

2 Answers

Bob Aiello's picture
Bob Aiello replied on December 29, 2013 - 12:39am.

Ajay,

most SVN users have a trunk for latest work, tags for creating baselines and branches for creating variants.

In my opinion it would be a very bad idea to delete the trunk because it would confuse many of your users who have experience working with SVN. There are also other reasons as you noted including the loss of history. I am actually not quite certain why you would even want to do this.

You should use branches to create variants and tags to mark milestones including production releases.
Then you svn copy the tagged release to a new branch when you need to create a bugfix.

trunk should always be your latest and greatest development effort.

Keep in mind that merging can be a challenge in SVN and using SVN in a non-standard way could lead to other problems as well.

Bob Aiello, Technical Editor

Ajay Kanse's picture
Ajay Kanse replied on December 29, 2013 - 7:14am.

Hello Bob,

First of all thank you for your time and response to the question.

I totally agree that we should be using branches to create variants and tags to mark milestones including production releases and then svn copy the tagged release to a new branch when need to create a bugfix. Trunk should always be your latest and greatest development effort.

The branching model that we use is branch by release. So for every release we create a new branch ( except first release which happens through trunk). The branch gets created either from the latest work in progress branch or trunk whichever is latest in point of time.

Developers try to delete the trunk after code goes to production mainly to avoid the branch to trunk merge activity which creates lot of conflicts and need attention at file level which sometimes cause unexpected merges etc. Also they feel that if they merge branch that was released to production in trunk, they can not assure that the code is not changes due to merging which is true sometimes based on what point merging is happening.

Also they try to avoid creating tags because trunk represents the production code. The understanding is historical branches if named properly can be reverted any time if required.

So basically at this point i am looking for a way or example to justify that deleting trunk is not good practice.

 

Any thoughts would be appreciated.

Thanks,

Ajay

 

 

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.