CODEWITHSUNDEEP
svnmergetortoisesvnbranch
Snowy Coder Girl
Snowy Coder Girl

Reputation: 5518

Erase a Subversion Branch

I was assigned to merge a few branches back into the trunk in Subversion. Currently the project setup is something like the following.

trunk
branches
    BranchA
    BranchB
    BranchC
tags
    // A bunch of tags (1 per release)

The goal is to integrate BranchA and BranchB back into the trunk and then have them "hidden" somehow.

I think I know how to do the actual merge. Right click the trunk in a Windows Explorer and TortoiseSVN > Merge... then Reintegrate a branch, choose the branch, then merge.

Question 1 - Is this the correct method to use?

I am also unsure what the repository will look like after I do this. We want to make sure no future developers mistakenly work on the old branches.

Question 2 - Will the branch be unworkable after the merge, or will we need to do something else? Can you "delete" a branch? If so, what will happen to the branch history? Or would we need to do something hacky like apply locks to the branch?

Thanks for any help.

Upvotes: 1

Views: 77

Answers (2)

Ferruccio
Ferruccio

Reputation: 100728

Question 1 - Is this the correct method to use?

Yes, that will merge the contents of the branch into your working directory. Nothing will happen to the repository until you commit the (newly merged) trunk. Once you commit not only will the trunk changes be in the repo, but it will remember what was merged in from the branch.

Question 2 - Will the branch be unworkable after the merge, or will we need to do something else?

At this point you can delete the branch or you can keep making changes to the branch. If you keep making changes to the branch and later do another merge, only the new stuff (not the stuff that was previously merged) will be merged into the trunk.

If you do want to delete the branch, the easiest way I've found is to open the repo browser, right-click on the branch and select "Delete". The branch will disappear from the latest version. It will still be in the repo history and you can bring it back if necessary, but someone doing a fresh checkout will not see it.

Upvotes: 2

gavenkoa
gavenkoa

Reputation: 48893

From command line (answer to question1):

$ cd $DEVROOT/trunk

$ svn merge http://company.org/svn/proj/branches/BranchA
....
$ svn ci -m 'Merged BranchA'
$ cd rm -m 'BranchB already merged' http://company.org/svn/proj/branches/BranchA

$ svn merge http://company.org/svn/proj/branches/BranchB
....
$ svn ci -m 'Merged BranchB'
$ cd rm -m 'BranchB already merged' http://company.org/svn/proj/branches/BranchB

Merging trunk to branch and merge back merge to trunk is not valid usage of SVN. Why - read:

I can't answer to your question2 as don't know your real requirements... I recommend to read official guide:

and suggest to use features leaf for feature-development and branches leaf for long-term version supports and tags for releases.

And don't recommend to remove any branches. Why? Because removing in SVN doesn't make repository smaller... Only make svn ls output shorter...

Look to my guide:

  • Each major release have own branch.
  • Another single branch reserved for development.
  • Latest major relase branch is active. All older major branches is passive.
  • Passive major branches was used for only for minor bug fixes on latest code from this major version series (no new features).
  • Features developed in development branch. Before release in merged to active major release branch.
  • Bug was fixed in oldest major version branch for which it must be provided and merged to all next major version branches and development branch.
  • Release means finish developing set of features and bug fixes on branches and moving product build to release server..

  • After testing and stabilising release was made. This means:

    • VERSION file was updated.
    • CHANGE file was filled with feature set, version, data and VCS revision number.
    • Mark release by tag in VCS.
    • Invoke build of sources which marked by tag. Copy result to release server.

  • If bug discovered in some version, it fixed at development branch and released with new minor/fix product version.

  • Previous major/minor releases do not supported (just use latest release). Users always forced to update to latest release.

Here t - tags, b - branches:


  +--+-----+----------------------+-----+----+------+------+----->
  dev|     |            ^     ^   |     |    |      |      |
     |     |            |     |   |     |    v      v      v
     |     |            |     |   |     |    +--+------+------+-->
     |     |            |     |   |     |    b2 |      |      |
     |     |            |     |   |     |       v      v      v
     |     |            |     |   |     |      t2.0.0 t2.0.1 t2.1.0
     v     v            |     |   v     v
    t0.1.0 +---+------+-+---+-+-----+------+------+------+------+--->
           b1  |      |     |       |      |      |      |      |
               v      v     v       v      v      v      v      v
              t1.0.0 t1.0.1 t1.0.2 t1.1.0 t1.2.0 t1.2.1 t1.2.2 t1.2.3

In this example we release tags 1.0.1 and 1.0.2 with bug fixes in branch 1 as development branch was not ready for production.

Upvotes: 1

Related Questions