svn: nuances in merging workflow

We have a repository with a trunk, occasional feature branches, and some persistent developer branches (because we each work on particular areas of the project).

The trunk is managed by our project manager, and except in emergencies, he's the only one to reintegrate a branch back into the trunk. The reintegrate-into-the-trunk operation is also something that's pretty clear to do. What we are having trouble with is what to do in our branches. (Side note: we use TortoiseSVN in preference to the command line.)

Our developer branches have gotten out of sync, and in trying to read up on the issue, I'm confused about the workflow, and the pluses/minuses of these approaches:

1. symmetrical resync between branch B and trunk by following these steps:

   • merge --reintegrate from B into trunk
   • merge --reintegra开发者_C百科te from trunk back into B

2. asymmetrical resync:

   • merge --reintegrate from B into trunk
   • merge --record-only from trunk into B (how do you do this in TortoiseSVN?)

3. reintegrate-and-restart:

   • merge --reintegrate from B into trunk
   • delete B
   • copy trunk to B to start anew

4. one-way resync from trunk to B:

   • merge from trunk to B
   • (repeat as necessary until it's time to reintegrate into the trunk.)

We were proceeding well with option #1 (symmetrical resync), and I'm really confused why #2 and #3 seem to be the recommended approach.

Can anyone explain this?

Also, what's the right way to merge between branches B and C to exchange updates w/o re-merging to the trunk first?[I will ask separate question]

---

I personally prefer option 3. Whenever you do a merge, Subversion keeps track of what revisions you're merging and from where. It does this in a super secret (reads: public knowledge but don't edit it) property called svn:mergeinfo. How SVN stores this merge information gets complicated, and depending on how familiar your developers are with the merge process, it can get very very messy.

By merging B back into trunk, the trunk gets svn:mergeinfo stating that B, between revision X and Y, is now on the trunk. Then, by deleting and creating B fresh from the trunk, B now has all the necessary history and svn:mergeinfo (since the svn:mergeinfo property got merged too) for logs to know which revisions exist in the branch (and which don't). It also helps avoid tree conflicts (which nobody likes).

Option 2 can be very dangerous. A company I worked for outright banned record-only merges (it became a fireable offense) because if done incorrectly, code can go missing. The theory behind it, though, is that when you re-integrate B into trunk, trunk has all of B (and svn:mergeinfo to match). Doing a record-only into B assumes that B won't be used for production code (because it won't have all the latest updates) and the record-only merge will provide some information to prevent tree conflicts (which, again, nobody likes).

Option 1 is a good in-between. Your branch B will get very cluttered with svn:mergeinfo, but since it's super secret (reads: handled mostly seamlessly) unless you have a huge number of merges, it should serve your needs fine.

---

Everything you need to know about what Reintegrate merge is, what it does, and why its done that way:

http://blogs.collab.net/subversion/2008/07/subversion-merg/

summary: its all about revisions that are 'synced' between branches, when you come to merge you expect it to correctly remember which revisions you want to merge, and which you want to exclude as already merged. The reason this is an issue is that sometimes you want to include those revisions where you had to manually resolve conflicts - you don't want to do them again; but generally you don't want to include those revisions. So reintegrate adds the intelligence to manage this, but at the cost of the usual flexibility - you cannot reintegrate over and over, you have to restart after reintegration. So option #3 is the only recommended one from the subversion guys.