SVN TRUNK way out of date with TAGS, most efficient way to merge?

With SVN, our usual operating process is a developer will create a development branch, makes some changes, test it, tag it, and that tag will be pushed to prod. Then the "Merge Master" will merge those changes into trunk. The problem is that there was some mis-communication about who was the merge master. So now we have an out of date trunk on these repos and who knows how many tags that aren't merged into trunk.

We are stopping development to tackle this problem and I was wondering anyone has had a similar problem and come up with an e开发者_如何学Pythonfficient solution

---

Tags are not meant for merging back. They are meant to be aid as bookmarks, to put it crudely. You have to merge back the "development branch", don't look at tags, even if that is how you were doing it before.

---

I believe you guys are going about your development process wrong. What should happen is everyone branches from the trunk to make a fix or add some new features and then that person merges back into the trunk. Then you always tag from the trunk. With this everyone is their own Merge Master and you don't run into any problems with an out of date trunk because people are constantly merging their changes back into it. Also this way your tags will always have everyones new features that are tested and ready to be in the main baseline.

Now with your current problem, everyone who has a branch should merge into the trunk right now and then you have a working copy of everyone's "tags" in the trunk.

---

I would think of the process as going like this:

1. Create dev branch
2. make changes while merging the trunk in from time to time to maintain stability
3. merge final dev changes into the trunk
4. tag the trunk
5. push the trunk

Tags are only meant to be used a snapshots of work as it's released (typically) for production. Once they're made they should be left alone for posterity.

I would recommend reading the SVN read bean book

---

Sorry if this sounds like a snippy answer, but: Yes, we had the same problem. We stopped creating new tags for every project. Merging is a nightmare. Every merge carries risk: If you get merge conflicts, somebody has to figure them out. But the worst possible scenario is that you DON'T get merge conflicts and the resulting code compiles successfully ... but it isn't right.

For the last few months we've taken a totally different strategy: To the greatest extent possible, we do all development on trunk. We usually start working on the next release about the same time that the current release is handed over to the test group. So when we go to testing, we peel off a "release branch" tagged with the release number. Any bug fixes are made to trunk, and then merged into the release branch. This means that the bug fixes are tested as part of ongoing development. Also, there's no way we'll forget to do the merge: If we did, the testing group would promptly complain that the bug wasn't fixed. As the release branch is just a couple of weeks behind trunk, there are rarely merge issues, and when there are, the programmer who made the change is readily identifiable and available because he just made the change yesterday.

PS I'm the "merge master" as you put it for our team. That sounds impressive: I might start calling myself that.