Use TortoiseSVN to merge branch changes with the trunk

Using TortoiseSVN, I need to take changes I’ve done in a branch and then merge them with Trunk.

I am the only developer on this project, so I know trunk hasn’t changed. I am learning SVN so that eventually my team can use it.

  • Change Git Parent Branch
  • Can a ref stored outside refs/heads be considered a branch and checked-out and worked-on as a normal branch?
  • How do I run git log to see changes only for a specific branch?
  • Does git know which branch is which after a merge?
  • Git pull a certain branch from GitHub
  • what is the difference between tag and branch with git?
  • Basically, I want my trunk to look exactly like the branch.

    In pre-svn world, I would just copy the files in my branch folder, delete the files in the trunk folder, and then copy branch into trunk.

    In TortoiseSVN, I’ve tried “Reintegrate a branch”, “Merge a range of revisions”, and “Merge two different trees.” Nothing seems to actually change trunk. I’ve also tried branching on top of the trunk. This gives me an error, saying that the trunk already exists.

    At this point, I am just ignorantly button mashing hoping something works.

  • Advantages of branching in Git (for an SVN user)
  • Switch branches without losing uncommitted work
  • Hg equivalent of “git log master..HEAD” when using bookmarks as lightweight branches?
  • Is there a mercurial equivalent to gits no-fast-forward merge?
  • Can I make git smarter when figuring out if it's okay to delete a branch?
  • Git: Merging two remote branches
  • 3 Solutions collect form web for “Use TortoiseSVN to merge branch changes with the trunk”

    In your case:

    1. Switch the working copy to the trunk (SVN Switch)
    2. Merge the branch into the working copy (SVN Merge)
    3. Make sure everything still compiles and works
    4. Commit the working copy (the trunk)
    5. Consider killing the branch

    In a team environment I would suggest that you first merge the latest modifications from the trunk in your branch, make sure that everything compiles and works, then do the above steps (which will be trivial since you’ve already tested the changes).


    In step 5, I mention killing the branch. That’s because once a branch from a feature is in the trunk, it should be considered as part of the trunk. In that case the branch should be killed so that no one keeps working on it. If major modifications are needed for that feature, you should create a new branch for that.

    The only branches that I don’t kill are maintenance and release branches, unless a particular release is no longer supported.

    No matter what, you always have access to every revision so killing a branch is only used to prevent other developers from developing on a dead branch.

    I think in TortoiseSVN 1.8.5, Merge | Merge two different trees should work. When you merge a branch/tag back to trunk, the trick is that the From URL is the trunk and the To is the tag/branch. Weird but true.

    Source: Merging

    For directories that not in your working copy but are in the tag/branch you may get conflict errors. Just accept the conflict and redo the merge.

    First switch your working copy to the trunk.
    Then do a merge range of revisions, from the branch to trunk.
    Once this dialog is complete the differences will be pending changes in your working copy of trunk. You’ll need to commit them just as if you manually made the changes on your working copy.

    In my usage, its more typical to keep trunk running and spin branches off at the times of builds. So then the only merge I ever need to do is to get a bug fix out of trunk and put it on the latest build branch and re-release that branch. The easiest way for me to do this, since as you have found merging is clumsy at best. Is to keep the latest branch and the trunk checked out to my machine, and to quite literally copy the files from trunk to branch and check both in.

    Git Baby is a git and github fan, let's start git clone.