On Tuesday, August 14, 2012, Greg Reddin wrote: > On Mon, Aug 13, 2012 at 10:29 PM, Omar Gonzalez > <omarg.develo...@gmail.com <javascript:;>> 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 >
It sounds like hell to me. -omar
