CODEWITHSUNDEEP
svnmergemergeinfo
Kaku
Kaku

Reputation: 119

how svn merge behaves during merging from branch to branch with different code base

We have different branches in SVN and do svn merge between branches. Each branch is nearly related to each other as our code is incremental. Suppose if there are around 5 branches (Branch 1 ,Branch2 ,etc .... ) at a time and branch X is merged into branch Y at some timeline and both branches has their own code development also:

Now if branch 3 also has code base as of branch 1 with its own changes i.e (Code Base A + Branch 1 changes + Branch 3 changes ). Branch 4 (created from branch 1 and has its own changes too )

Right now I am facing issues specially with deletion of code and duplication of code in same file.

Problems faced

Sometime a file which is not in conflicted state gets code content twice in file .And

Case of branch 3 and branch 4

code which is removed in branch 3 is visible again in branch 4 somehow although merging is done with forward approach (branch1 --> branch2--> branch3 --> branch4)

We tried keeping same base everytime but still get issues like above. I want to learn how merging should be done in above scenario. Please suggest your inputs.Any one with practical knowledge on svn merge will be very helpful .

PS: I already studied Merging best practices but now getting clear approach. I know basic approach of merging but never did merging in complex scenario like this

Upvotes: 0

Views: 99

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97365

  1. You try to implement "Branch per Task" workflow. It's OK, but selected tool - not OK
  2. All branches in Subversion have equal rights - you can merge any branch with any in any direction (if it really needed)
  3. SVN 1.8+ will give you some benefits
  4. For long-term branches, intensive branching and active usage cross-branch merges (with minimal headache) you selected rather bad SCM - any VCS with merge as "first class citizen" will be better and more usable choice: having SVN-background it seems to be Mercurial

Upvotes: 0

David W.
David W.

Reputation: 107090

You need to consider you branching strategy. It seems a bit complex. What do the four branches represent? Are they particular features you're adding in? Why the cyclical merging?

Let's designate one branch (branch 1) as your integration stream. This is the place where all work goes. It is the place where the release will be taken. Branch 2, Branch 3, and Branch 4 will be feature branches. Branches where you're adding features. In this case, all merging will take place between Branch 1 and the other branches. You don't merge code between any of the other branches.

Branching has been compared to having kids. If you have one, you better be prepared to take good care of it. You have to watch it and maintain it.

It's one of the reasons I try to keep branching to a minimum. All of our work is done on trunk, and I branch near release time to allow some developers to complete the upcoming release while other developers work on the future revisions. Once a release is complete, we say "au revoir" to that branch (unless we need to patch).

Occasionally, I'll make a feature branch. This is trickier because we must keep that feature branch in sync with the trunk. It's not hard to do, but the developer has to remember to do this on a regular basis. Otherwise, we all work off of trunk.

Other sites use feature branches all of the time, but must remember to merge their integration branch (or trunk) into these branches (to keep the feature branches up to date), and to be careful merging the feature branches back into trunk (which uses a different merge algorithm).

Upvotes: 0

Related Questions