Branching strategy for moving feature branch between versions

Question

At my workplace, we use an SVN repository for the source code, which holds the main application and some other projects, and for the main application it is structured like this:

- trunk
 - app
- tags
 - app
 - 16.2.0
 - 16.3.0
 - ...
- branches
 - app
 - 17.1.0
 - 00_master
 - 01_feature
 - 02_other feature
 - ...

So in the branches we have one container for each new release, and inside that there is a "master" branch, created using svn copy from the trunk, and one branch for each feature scheduled for that release, created by using svn copy on the master branch.

When a feature is complete, it is tested and then merged in the master for its version, and at the end, the master is merged into the trunk, which is then used to open another version branch.

However, it has happened that one feature couldn't really be completed for the version it was scheduled into and had to be postponed.

So, what I did, was to create the master branch for the new version, from that create the branch for the postponed feature, and then try to merge the old branch from the previous version with this new one.

However, the SVN client refused to perform the operation, due to the different ancestry of the two branches.

Is there another way, given this setup, to move a feature branch from one version branch to another? Or should we really change the layout here?

• Richard Smith: There is an option --ignore-ancestry which forces svn to rely on the diffs alone. That option is discussed here.
• Matteo Tassinari: That could work, since when using it I would know that: 1. the feature branch is in sync with the master of its revision; 2. the new version branch has just been created, with no other modifications in the middle... Do you happen to know if that option is available in the TortoiseSVN client?

Answer 1

You will have to do a cross branch merge. which is a pain.

A better solution might be to simply create a new branch and redo the features changes. ie copy them across from a download of the old branch and check them in a as a new commit.

You would lose your commit history for the work done so far, which is a pain, but avoid any merge problems

• Matteo Tassinari: Is the "cross branch merge" the same think suggested by Richard Smith in his comment on my question? That is, using --ignore-ancestry?
• Ewan: yes it is the same i believe