Replacing Branched project with current Trunk version of a Project in SVN

I have \trunk\root\ which contains folders ProjectA, ProjectB etc.
I have creates branch of root -> \branches\task\root\

Now I’ve made considerable changes to the projects in task including ProjectB.

  • SVN - how does removing a bin folder cause the src folder to be removed instead?
  • RabbitVcs and Commit
  • How to add a folder of a repository as a submodule to other repository using tortoiseGIT
  • PHP Site Deployment Suggestion
  • Converting a subversion repository to git, why am I seeing “fatal: not a valid object name”?
  • How do I add file to remote Git repo (Github) without cloning the whole repo first
  • However \trunk\root\ProjectB has also moved on to a point that makes all the changes in task\Root\ProjectB redundant.

    I would like to completely replace the content of \branches\task\root\ProjectB with the content of \trunk\root\ProjectB. No merging just make the task version ProjectB identical to the trunk version. Note when it comes to merging task back into trunk I don’t want any weirdness happening in ProjectB, SVN should just see that its an old version of what is now in ProjectB and not change anything in it.

    Can anyone guide an SVN know-nothing like me (who also happens to be a complete CLI whimp) through using TortoiseSVN to acheive this?

  • git-svn crashing on big repo migration
  • Get revision number of a remote repository
  • Nested version control scheme?
  • Trouble with SVN post-commit and Jenkins
  • git-svn: reset tracking for master
  • Is there a way to validate the presence of Javadoc and/or inline code comments?
  • 4 Solutions collect form web for “Replacing Branched project with current Trunk version of a Project in SVN”

    1. Delete the current ProjectB on the branch, do this on the svn repo
    2. Copy the trunk ProjectB onto that branch location again (where ProjectB used to be).
    3. Revert, or better still, recheckout ProjectB.

    That is if you’re okay with losing the history.

    An alternative approach where the history will be kept – but this will use the Eclipse IDE

    1. Checkout ProjectB from trunk
    2. Checkout ProjectB from branch (to a different project in Eclipse)
    3. Compare the two versions of ProjectB and bring in all the changes from the Trunk Project B into branch ProjectB
    4. Checkin Branch Project B
    1. Switch working copy to /branches/task/root/ProjectB (or checkout a new WC from this URL)
    2. Right-click and select Merge
    3. Select Merge two different trees
      • From: /branches/task/root/ProjectB
      • To:     /trunk/root/ProjectB
    4. Leave the other options at the defaults and click Merge (or Test merge)
    5. Resolve any conflicts by choosing the trunk’s version of the file

    This will bring in the necessary changes to make your branch the same as the trunk. Then you can commit.

    In Tortoise You can right click and do the equivalent of an “svn delete”, i.e Delete of the branch you want to kill.

    Then you need to do a Tortoise copy to and put in the new path.

    Normally you should regularly re-integrate changes made in the trunk to the branch to avoid that kind of situation.

    Why don’t you keep your previous branch, and make a new one instead? It’s quite common to use a version in the structure, as in:


    To do that with TortoiseSVN, move your branch by:

    • opening the repo-browser (context menu, TortoiseSVN -> repo-browser)
    • creating a branches/task/version1.0 directory (Create folder on task)
    • renaming branches/task to branches/task/version1.0 (Rename on task)

    Then you can proceed as normally:

    • (context menu on the checked-out trunk directory) TortoiseSVN -> Branch/Tag
    • specify the To URL of the new branch (branches/task/version2.0)
    • specify whether you want to make your new branch from the working copy or another place (I would strongly advise to commit first and branch from HEAD)

    (alternatively you could use the repo-browser and do a Copy to from the trunk)

    As the tools warns you, you still have to switch:

    • (context menu on the same directory) TortoiseSVN -> Switch
    • specify the To URL of the new branch (branches/task/version2.0)

    You will have something much cleaner that way.

    If you opt to delete the branch anyway, you’ll avoid any confusion when merging back by specifying the revision range to merge (one of the fields to fill in with TortoiseSVN). Make sure to exclude anything related to the deleted branch. But honestly, I would avoid that.

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