managing many small tasks

We have many small software changes and frequent releases (every 2 weeks). Everything that's ready to go when a release date rolls around is supposed to be included in the release; everything still in work is held back.    What's a smart way to manage this environment in SVN?    Our present strategy is that every project gets its own branch. When we're ready to do a release, we check out the "production" branch, merge in all branches for completed projects, and then commit this back to production.    The problem with this is that changes are often interdependent. So developers have to check out the branch for their current project, merge in another branch, and then somehow commit this back. Also, any conflicts between changes are invisible until the deployment person tries to do the merge. In practice, he then tries to buzz through the conflicts and clean them up as quickly as he can. I'm sure that if this hasn't resulted in incorrect conflict resolution yet, it will sooner or later.    In past jobs I've always maintained a single main-line branch with all ongoing work, and occasionally spun off an emergency bug fix branch, and that was about it. That works great in an environment where releases are on a sane schedule, but apparently not so well here.

Last updated 15 years ago

If one project is dependent on another, consider branching the dependent branch off the other, and not off the main line.    To the extent that there's a lot of interdependence, make a branch for all of it. You probably shouldn't be trying to treat things as separate if they all rely on each other.    I think it's best to minimize the amount of merges that the deployment person should have to do. Everything should be pretty well resolved before it gets to that point. In principle, the developers should be fairly aware of what's going on around them and be able to reconcile their own changes with that. I would plan my structure accordingly.    Let me know what you think.