0

Suppose that a company supports three versions of their software: 1.0, 2.0 and 3.0, and they have an SVN branch for each version. If a bugfix affects all three versions, they fix it on 1.0, then merge it from there to 2.0. It seems to me that they should then merge from 2.0 to 3.0. Is there some school of thought that says that they should instead merge from 1.0 to 3.0, even though they are more likely to encounter merge conflicts? What would be the reason for doing that?

(Some would say that they should fix the trunk and then merge down, in which case the question is essentially the same: after merging from trunk to 3.0, should they merge from trunk to 2.0?)

Note: I am aware that GIT uses a different branch/merge model. I am asking about SVN.

Dan R.
  • 761
  • 5
  • 21
  • Is this question of purely academical nature or is there a concrete problem behind it? The merge itself (i.e. applying a diff as a patch) is not more likely to create a conflict either way. The difference would be in svn metadata. – Friedrich May 03 '23 at 20:51
  • It's not just an academic question: I work at the said company. And we have found that when there is a conflict when merging from 1.0 to 2.0, we are very likely to encounter the same conflict if we merge from 1.0 to 3.0, but not if we merge from 2.0 to 3.0. – Dan R. May 03 '23 at 22:25

2 Answers2

0

The problem you are describing (including your comments) is due to the fact that the conflicting section of code is not being changed between 2.0 and 3.0. Once you take care of the conflict when merging 1.0 into 2.0, when trying to merge the result into 3.0 won't cause a conflict there given that the section of code is not modified between 2.0 and 3.0.... however, if you tried merging 1.0 into 3.0, that section of code would be modified in the 3.0 branch since they diverged and then you get the conflict.

disclaimer: Take that with a grain of salt given that I am more of a git guy but I bet logic there is the same in svn.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
0

Your question has everything to do with your code and nothing with subversion.

Explanation

Your versions 2.0 and 3.0 seem to be closer related. Once you merge your fix into either of them and resolve the conflicts, propagating the merged revision will not cause the same conflict again. Because, well, you already resolved it in your code.

This paragraph applies to any VCS - because it has nothing to do with VCS.

Peculiarities of Subversion

What's special about subversion is that it stores the information on what was merged into what as a property svn:mergeinfo (read more about it in the Red Bean Book). Basically, it keeps you from applying the same changes twice. See What's SVN's actual use of mergeinfo? for an exhaustive explanation.

Subversion is pretty good at tracking mergeinfo. Is it so good that it never fails? Obviously not, as the writers of the Red Bean Book felt compelled to write a Final Word on Merge Tracking.

Note that it covers some esoteric cases but does not forbid your 1.0 -> 2.0 -> 3.0 merge. So it should be fine.

The Answer

So the answer seems to be "it doesn't matter".

From a developer's point of view I'd be tempted to use whatever is less effort.

But wait ...

The Red Bean Book also has a word on Release Branches and suggests the trunk -> branches/release merge.

Subversion has one special branch, called "trunk", by convention. The idea is, that the newest version of your software lives on trunk. Anything else is either a feature branch, a release branch or a tag.

You found a bug that needs to be fixed in three releases of your software (I don't know how many releases you have but I'll assume three). Wouldn't it be best to fix the bug on trunk and then propagate it to the releases? Not necessarily from a technical point of view but from a logical point of view. Doing so will cause least astonishment if somebody takes a look at the revision graph after some time.

Food for the trunk-to-release school of thought.

Friedrich
  • 2,011
  • 2
  • 17
  • 19