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.

  • .NET projects build automation with NAnt/MSBuild + SVN
  • Migrating to GIT from SVN
  • Handshake failure with “SSL error code -1/1/336032856” on OS X 10.7
  • checksum mismatch on subversion merge
  • How to mirror trunk of svn repo into github?
  • git svn clone large repo under Windows: out of memory - not a large file issue
  • 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?

  • How to quarantine a specific subversion revision?
  • Is there a way in a VCS to have a child branch that only syncs a few specific folders/files from the parent?
  • version control for newbie
  • Converting from SVN to Git with submodules
  • How to make deleting .svn directories work using ant?
  • Distributed version control for HUGE projects - is it feasible?
  • 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.