On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez <omarg.develo...@gmail.com> wrote: > The way I see it, if there are a bunch of developers working in trunk, and > they happen to leave things unfinished or unstable, then somebody has to go > through all of that and figure out what is actually ready for a release and > what is not. Without a well defined SVN strategy this is going to be a mess > that someone will have to clean up.
Everyone is working in trunk. Some things are unstable. A discussion starts up on list that it's about time we cut a release. We either decide to: 1) move some stuff from trunk to a branch so we can make a release from trunk, or 2) cut a branch from trunk and make a release from the branch. Either way we spend some time either getting trunk stable for a release or getting a branch stable for a release. Then we make a release and work goes on. Personally, I wouldn't commit any unstable code to trunk. If I'm working on something that's going to span more than one or two commits, I'd do it in a feature branch. When the feature branch is done I merge to trunk. Here's a use case: Greg wants to implement better Maven support and Alex wants to refactor UIComponent at the same time. Both of these are long-running efforts that touch a lot of code. Nobody knows how big either one really is or how long it will take. So here's a script of how it might play out: 1. Greg: svn cp trunk branches/maven-support 2. Alex: svn cp trunk branches/UIComponent-refactor. 3. Over the course of two or three weeks people commit to both of these branches. People also commit to trunk. 4. Periodically Greg and Alex run svn merge trunk in their branches to keep the branches up to date with trunk. 5. Om decides to make a release from trunk, so all effort in trunk goes toward making the release. Work continues in the two branches. 6. Release is cut from trunk and a tag is created. 7. Greg and Alex continue to run svn merge trunk to keep their branches up to date. 8. Alex completes his work first because he's much faster than Greg :-) 9. After some discussion on flex-dev everybody agrees Alex's work is worth integrating. 10. Alex does a final svn merge trunk in his branch to get the latest updates. 11. Alex goes to trunk and runs svn merge --reintegrate branches/UIComponent-refactor, 12. Alex makes a commit to trunk. 13. Greg does another svn merge trunk in his branch to get the UIComponent refactor. 14. Alex makes a release from trunk. 15. Greg repeats step 13. 16. Eventually Greg & team *finally* finish their work. 17. After discussion on flex-dev everybody agrees that Greg's work is indispensable and needs to be integrated. 18. Greg does a final svn merge trunk in the maven branch to bring over latest changes. 19. Greg does a svn merge --reintegrate branches/maven-support in trunk. 20. Greg makes a commit to trunk. 21. Greg makes a release from trunk. ... Notice a few things: * Potential pain points come in step 7 because the released code might be hard to integrate into the branches, and particularly steps 9 - 12 and 16 - 20 because we're reintegrating significant changes back into the codebase. However these pain points are at isolated, atomic stages along the way. * Notice the discussion that takes place at step 5, step 9, and step 12. When we are ready to make a release we talk about it. Everybody works together to make it happen. When we are ready to integrate significant progress we talk about it and everybody works together to make it happen. It's not perfect. It's not necessarily fast. But it's proven to work for a lot of apache projects and it doesn't get much simpler. Greg
