How can I manage merging updates from several developers? [closed]

Question

I work with a mid-sized team of developers all working on one product. Developers write the code to address a feature or bug fix ticket, then check it into our main development branch (in Subversion). Once the ticket has been tested and validated there by the QA folks, I merge it into the trunk. I normally do this manually, since a lot of the tickets span several revisions, which are not always sequential and may include fixes for several tickets at once.

One thing that I'm sure would help is encouraging developers to only checkin one ticket per revision. We use Jira to track our tasks, so every Subversion revision should have a Jira issue ID in the log - when I'm merging code, I go looking for revisions that include the issue I'm merging in.

Are there other ways I could manage this better? Do other teams branch off of the trunk for every ticket and issue? As I said, we have one main development branch, at least partly because we are building a lot of new functionality pretty quickly, and I imagine we would wind up with dozens of branches pretty quickly if we made one for each ticket.

Answer 1

This question has nothing to do with DVCS or not. It's a PROCESS issue, not a technology issue. Here's my take on what a lot of people are doing, and the process that ClearCase UCM promotes:

/project/trunk 
        /branches 
            /release-1.0-JIRA1023
            /release-1.0-darthcoder-JIRA1029 
            /darthcoder-JIRA1029

        /branches/release-1.0-tfix   <- This is the patch trunk.  Main trunk is future dev

When I fix my bug, I'll promote it back to trunk, or the to the specific release I'm trying to fix. I'll merge to release-1.0-tfix, and to trunk, because it needs to be fixed in several places. When I'm done, I delete the branch and move on to the next issue. So I have two branches of code with the JIRA fix in it while I'm testing it and working on issues (if the fix is wildly divergent).

But nothing gets promoted to trunk or the -tfix trees unless a successful build/test cycle is run, and it has a JIRA property for tracking. This way you can tie each individual fix back to a developer, a branch, and verify things get fixed properly. Also that issues don't get lost (oh did JIRA1029 make it into version 1.2? Well you can verify that by looking for JIRA1029 in your repository. You never have to GUESS, and that's what makes software development repeatable and gets us closers to bugs == 0.