1.

First of all make sure you are up to date.Update your working copy of the target branch, ie. where you are merging into.In this example we're working on the trunk of "core" and we want tograb the changes that have happened in the maintenance branch and merge them.

2.

Resolve any conflicts. There should be noconflicts at this stage between the working copy and the repository.

3.

Select the SVN merge option on the workingcopy. In Eclipse this is going to be found under the "Team" menu andcalled "Merge Branch". SVN: Merging in Eclipse

4.

Change the From URL to the specific branchyou want to be merged into your working copy. In this example we're looking forthe p400 maintenance branch (./core/branches/p400).

5.

Change the From Revision to the lastrevision that was merged into the target branch. Essentially you don't want tokeep merging the whole branch history, you just want to include those changessince the last time you merged. There is no easy way to determine the lastmerge point at this time in Subversion. You have to review your message log andlook for the last commit that talks about merging. If you are disciplined aboutthe commit messages you use for merging this should be easy (see below). Make anote of what that revision is -- you'll need this later when you commit yourchanges. SVN: Merge with Eclipse

6.

Change the To Revision to the latest (i.e.head). Make a note of what that revision is -- you'll need this later when youcommit your changes.

7.

Click Merge and wait. Depending on how bigthe differences are this may be quick or Eclipse my just fall over. If you havesuch an enormous change that you can't get it done in Eclipse you may need tomake the range of revisions you are merging smaller. Or you may even have toskip certain revisions and do them manually if they are massive. We've had thisproblem from time to time when updating large third-party libraries. The vastmajority of the time you will be fine.

8.

Review changes and resolve conflicts. Oncethe merge is complete, look through the changes made to your working copy andmake sure you address any conflicts you find.

9.

Once all the changes have been resolved inthe target working copy, check them in with a single commit. The reason you'renot doing lots of commits is that these are changes that should have beendocumented in the branch from which you merged. The commit message needs to bein a specific format that details the merge and is easy to find in the future.We use the following format, but you can use anything that works for you -- aslong as you stick to it.

Merging [source] to [target]; [repository].Merge rev [start]:[end]