While working with one project I was assigned to, I noticed a small problem with our SVN strategy. A few months ago, someone created a new feature branch from our trunk. In this branch he implemented a second implementation of an already implemented feature (but in a  more efficient way). He changed actually only one class.After this action some of the classes methods are common for both places - trunk and feature branch - but some methods are specific for each implementation. It was decided that we have to support both version so sometimes we create a deploy from branch, sometimes from trunk (some business assumptions). Now I have some problems with merging - normally I want to merge only these code parts which are common for trunk and branch. It makes each merge more complicated because each time I have conflicts to solve (and I have many of them) I have to pay extra attention to what action should I take for each conflicted line. My question is: am I right in claiming that the decision of creating a new version which should be supported as a feature branch was a bad idea? What are the best practices in such case?
SVN best practices - different code logic in branches
svn;branching