3

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?

  • 1
    Feature branches should live short in general. So merging into trunk, with for example a feature switch, will prevent those issues and allows to have the class around for a longer time without much issues. – Luc Franken Aug 29 '16 at 7:35
4

That is, you have now two classes sharing some code. Do they still look the same from an outside point of view, i.e. have the same signatures of their public methods?

If so, create a base class for the common features, and two derived classes. You may need to change the name of at least one of them. Now both versions are included in your executables. At runtime, let some configuration system (e.g. a Dependency Injection container, or some simple solution) decide which of the classes to use.

Your assumption is right, the branch is not a correct way to handle this.

  • Thanks for answer. Unfortunately, some public methods take a little different input parameters (for example connection object instead of url). – guitar_freak Aug 29 '16 at 8:28
  • 1
    @guitar_freak so, you could apply adapter pattern to use the same interface. – Q Q Aug 29 '16 at 11:10
  • 1
    @guitar_freak: Such differences in public interface should be reconciled when you merge the feature branch back to trunk. As it is, your two branches will diverge from each other and the longer you keep both branches, the harder it will be to reconcile the changes that have (unintentionally) been made to only one of them. – Bart van Ingen Schenau Aug 29 '16 at 12:03
  • @guitar_freak: to your example: the "connection object" instead of an "url" could be injected through the constructor of the derived classes. The constructors will have different signatures either, so the public methods of the two classes can have a common interface. To switch between the classes, you need to introduce a feature toggle into the code. – Doc Brown Aug 29 '16 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.