CODEWITHSUNDEEP
version-controlsvn
Eric Belair
Eric Belair

Reputation: 10692

How can I merge two SubVersion branches to one working copy without committing?

My current SubVersion workflow is like so:

  1. The trunk is used to make small content changes and bug fixes to the main source code.
  2. Branches are used for adding/editing enhancements and projects.

So, trunk changes are made, tested, committed and deployed pretty quickly. Whereas, enhancements and projects need additional user testing and approval.

At time, I have two branches that need testing and approval at the same time. I don't want to merge to the trunk and commit until the changes are fully tested and approved.

What I need to do is merge both branches to one working copy without any commits.

I am using Tortoise SVN, and when I try to merge the second branch, I get an error message:

Cannot merge into a working copy that has local modifications

Is there a way that I can do this without committing either merge?

Upvotes: 1

Views: 5298

Answers (5)

Lazy Badger
Lazy Badger

Reputation: 97280

Eric, " I may want to only deploy one change at a time..." and "merge two branches to one working copy without committing" are incompatible requirements: or you'll test branch after branch or mix two branches in one big mix.

Version A Anyway - you can merge any node with any node inside repo-tree, not only somebranch with trunk. I.e., in common, @JoelFan workflow is good, but - require less actions

  1. copy HEAD of trunk to AB
  2. Merge AB with A
  3. Commit mergeset, test etc...
  4. Merge AB with B
  5. Test merged results
  6. Merge to trunk and delete temporary AB-branch

Version B is 2-URL merge. svn help merge, "2-URL Merge Example" part as start. You can merge 2 independent branches into third in one command merge BRANCHA[@N] BRANCHB[@M] [TRUNK_WCPATH]

Upvotes: 1

Marcin Sanecki
Marcin Sanecki

Reputation: 1334

Every merge operation is done in your local sandbox. You do not have to be worried until you commit some junky code.

I don't know the whole deploy process you do but what you can do is:

  1. switch to branch A
  2. merge branch A with branch B
  3. build the app, deploy and test it

If all works fine you can commit all changes (you are on branch A). Then you can switch to trunk and merge with branch A. After all conflicts are solved you can commit on trunk and that is all.

Upvotes: 1

gbjbaanb
gbjbaanb

Reputation: 52659

you can checkout another copy of the branch you want to merge into at a different place on your local drive, merge into it and then commit it. Then delete the whole 2nd working copy and return to your current task.

But it does seem that you are trying to subvert your own working practices - unless you want to just merge 2 branches together to commit all the work simultaneously and delete the 2 old branches... but then, what's stopping you from committing to them and merging normally in such a case?

Upvotes: 1

Wyatt Barnett
Wyatt Barnett

Reputation: 15673

We had a similar workflow at one point. The solution I finally landed on was to keep multiple local copies, basically one per branch. Got a bit dicey at times with shared databases but overall it was very successful.

Upvotes: 1

JoelFan
JoelFan

Reputation: 38704

You currently have the trunk and 2 branches A and B (which are both branches from the trunk). I suggest you create yet another branch called AB as follows:

  1. Switch your working folder to the trunk, if not there already
  2. Update the latest and make sure you have no local modifications. If you do, either commit them (to the trunk) or revert them as appropriate.
  3. Do one last update of your working folder from the trunk. Note the revision number you have updated to (call it revision R).
  4. In the repo, copy revision R of the trunk to a new branch called "AB" (Do not switch your working folder to AB yet)
  5. Merge your working folder with A.
  6. Switch your working folder to AB.
  7. Commit your working folder (to AB) and update (from AB).
  8. Switch your working folder to the trunk.
  9. Merge your working folder with B.
  10. Switch your working folder to AB.
  11. Commit your working folder to AB.
  12. Test, and commit any fixes to AB.
  13. When it's working and you're ready to merge everything to the trunk, do a final commit (to AB), then update your working folder (from AB).
  14. Switch your working folder to the trunk.
  15. Merge your working folder with AB
  16. Test and fix
  17. When it's working, commit working folder to the trunk.
  18. Go out for beers

Upvotes: 2

Related Questions